Re: [whatwg] Conformance checking of missing alternative content for images
On Fri, 7 Sep 2012, Benjamin Hawkes-Lewis wrote:
> On Fri, Sep 7, 2012 at 6:12 AM, Ian Hickson wrote:
> > On Sun, 26 Aug 2012, Benjamin Hawkes-Lewis wrote:
> >> >>
> >> >> It would help catch the not uncommon antipattern where the
> >> >> "content" of a link or button is provided only by a background
> >> >> image.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> > This is should-level non-conforming and has no reason to be
> >> > conforming, as far as I can tell ("elements whose content model
> >> > allows any flow content or phrasing content SHOULD have at least
> >> > one child node that is palpable content and that does not have the
> >> > hidden attribute specified").
> >> >
> >> > The only reason it's not entirely non-conforming ("must" rather
> >> > than "should") is that there are some edge cases where it makes
> >> > sense, e.g. when you have an empty paragraph that you're going to
> >> > fill in later.
> >> >
> >> > But maybe we should tighten this up again, e.g. for interactive
> >> > content?
> >>
> >> I cannot imagine a good reason to include an unnamed control, so yes.
> >>
> >> Note that this would need to take into account that fields might be
> >> labelled by a or a table header cell.
> >
> > Hm, that's a good point. I don't think there's a good way to
> > programmatically detect whether there's a label or not, so I'll just
> > leave it as a SHOULD for now.
>
> That doesn't make any sense to me.
>
> For browsers to expose an accessible name for a field or control, they
> must compute it from the DOM.
Yes, but they might not always be able to expose one without it being a
problem. For example, consider a "Battleships"-style game where the board
is a grid of cells where each cell is labeled with a row and column name
("column B, row 5", etc). The buttons don't have to have explicit labels
for the buttons to legitimately be said to have labels. Yet we have to
distinguish this case from a cell that has an unlabeled "edit" button that
isn't related to the cell headings. I don't see how you'd do that
programatically.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Conformance checking of missing alternative content for images
On Fri, Sep 7, 2012 at 6:12 AM, Ian Hickson wrote:
> On Sun, 26 Aug 2012, Benjamin Hawkes-Lewis wrote:
>> >>
>> >> It would help catch the not uncommon antipattern where the "content"
>> >> of a link or button is provided only by a background image.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> > This is should-level non-conforming and has no reason to be
>> > conforming, as far as I can tell ("elements whose content model allows
>> > any flow content or phrasing content SHOULD have at least one child
>> > node that is palpable content and that does not have the hidden
>> > attribute specified").
>> >
>> > The only reason it's not entirely non-conforming ("must" rather than
>> > "should") is that there are some edge cases where it makes sense, e.g.
>> > when you have an empty paragraph that you're going to fill in later.
>> >
>> > But maybe we should tighten this up again, e.g. for interactive
>> > content?
>>
>> I cannot imagine a good reason to include an unnamed control, so yes.
>>
>> Note that this would need to take into account that fields might be
>> labelled by a or a table header cell.
>
> Hm, that's a good point. I don't think there's a good way to
> programmatically detect whether there's a label or not, so I'll just leave
> it as a SHOULD for now.
That doesn't make any sense to me.
For browsers to expose an accessible name for a field or control, they
must compute it from the DOM.
If it is possible for browsers to compute it from the DOM, then it is
possible for a linter to compute it from markup.
If the linter computes an empty/whitespace string, that (should be) an error.
The algorithm for computing names from the DOM can be fully defined.
If it's not defined, and author conformance requirements are not
aligned with that definition, that's a failure of specification.
That the algorithm for computing names is not *entirely* trivial does
not mean we cannot define it or have MUST-level conformance
requirements around it (q.v. HTML parsing, image alternate text,
etc.).
--
Benjamin Hawkes-Lewis
Re: [whatwg] Conformance checking of missing alternative content for images
On Wed, 22 Aug 2012, Jukka K. Korpela wrote:
> 2012-08-22 3:43, Ian Hickson wrote:
> >
> > [...] the argument is that WYSIWYG editor implementors will be
> > pressured into making their tools output conforming content by people
> > who don't understand the subtlties of this thread, based purely on
> > validator output.
>
> To which extent do people pressure WYSIWYG editor implementors into
> that, who are these people, and is there evidence of the pressure being
> successful? How often have they made implementors generate alt="" for
> unknown images, instead of something appropriate like alt="(an image)"?
alt="(an image)", or alt="DSK1298.JPG", or similar such strings, are
terrible alternative text. They're not uncommon. (I don't have numbers at
hand. I did look into it a few years ago. It would certainly be good to
have someone do more recent research.)
> > A user converting 100,000 PDFs to HTML isn't going to be entering
> > alternative texts for each image.
>
> Such bulk conversions can be useful for many purposes, but the results
> are not accessible and do not conform to good HTML authoring rules.
> There is no reason to prevent validators from saying this, in their own
> way.
There is a reason; it's been explained in some detail in this thread.
Briefly again: If they're not silent, the authors of those tools will be
pressured into making the images have bogus alternative texts that are not
programmatically detectable, by people comparing such tools using
validators. Better to have the output be clearly non-conforming, but for
the validators not to complain about it by default.
> Take the example of converting one non-HTML document with images to HTML
> format. Should the result of an automatic converter that generates
> tags without alt attributes be considered as valid as the result of
> human conversion with alt attributes added or semi-automatic conversion
> (where a human is prompted for entering alt texts)?
It's not valid to omit alt="" in these cases. We just don't want
validators to say that it's not valid.
On Sun, 26 Aug 2012, Benjamin Hawkes-Lewis wrote:
> >>
> >> It would help catch the not uncommon antipattern where the "content"
> >> of a link or button is provided only by a background image.
> >>
> >>
> >>
> >>
> >>
> >
> > This is should-level non-conforming and has no reason to be
> > conforming, as far as I can tell ("elements whose content model allows
> > any flow content or phrasing content SHOULD have at least one child
> > node that is palpable content and that does not have the hidden
> > attribute specified").
> >
> > The only reason it's not entirely non-conforming ("must" rather than
> > "should") is that there are some edge cases where it makes sense, e.g.
> > when you have an empty paragraph that you're going to fill in later.
> >
> > But maybe we should tighten this up again, e.g. for interactive
> > content?
>
> I cannot imagine a good reason to include an unnamed control, so yes.
>
> Note that this would need to take into account that fields might be
> labelled by a or a table header cell.
Hm, that's a good point. I don't think there's a good way to
programmatically detect whether there's a label or not, so I'll just leave
it as a SHOULD for now.
On Wed, 22 Aug 2012, Steve Faulkner wrote:
> >>
> >> The spec currently allows img without alt if the title attribute is
> >> present
> >
> > That's a wild over-statement of the case.
>
> In terms of conformance checking it is not, as you have said yourself
This is only a limitation of the state of the art. There's no way to
detect these valid cases vs the invalid ones, and reporting false
negatives ("you're invalid" when it is valid) is worse than false
positives ("you're valid" when it is not).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Conformance checking of missing alternative content for images
On Wed, Aug 22, 2012 at 1:43 AM, Ian Hickson wrote:
> On Sat, 4 Aug 2012, Benjamin Hawkes-Lewis wrote:
>>
>> Would it be possible to combine this with the linter complaining about
>> all controls (links, buttons, form fields) have markup that yield a
>> non-empty "accessible name" without invoking repair techniques such as
>> reading filenames without img @src attributes?
>>
>> http://www.w3.org/WAI.new/PF/aria/roles#namecalculation
>>
>> I realise the author requirements in the HTML spec seem to have
>> gradually become very forgiving here, not really sure why.
>
> I'm not sure I understand the suggestion here. Can you elaborate?
See also our old discussion at:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10710
>> It would help catch the not uncommon antipattern where the "content" of
>> a link or button is provided only by a background image.
>>
>>
>>
>>
>>
>
> This is should-level non-conforming and has no reason to be conforming, as
> far as I can tell ("elements whose content model allows any flow content
> or phrasing content SHOULD have at least one child node that is palpable
> content and that does not have the hidden attribute specified").
>
> The only reason it's not entirely non-conforming ("must" rather than
> "should") is that there are some edge cases where it makes sense, e.g.
> when you have an empty paragraph that you're going to fill in later.
>
> But maybe we should tighten this up again, e.g. for interactive content?
I cannot imagine a good reason to include an unnamed control, so yes.
Note that this would need to take into account that fields might be
labelled by a or a table header cell.
--
Benjamin Hawkes-Lewis
Re: [whatwg] Conformance checking of missing alternative content > for images
Hi Ian, I think the changes to the spec in regards to advice for use of title are a practical step in the right direction. >> The spec currently allows img without alt if the title attribute is >> present > > That's a wild over-statement of the case. In terms of conformance checking it is not, as you have said yourself, and others have echoed, most developers will not read the spec and therefore will not understand or take account of the nuances of when alt is required. The conformance checker on the other hand as per HTML LS will not flag this as an error which is a clear signal that it is allowed. While putting requirements into the spec on what browser implementers must do to conform with it is one thing, whether and when they do is what I am interested in, and for the past 19 years they have not provided input device independent access to the title attribute, lets hope that changes and until it does so conformance should reflect this fact. >> It is suggested that due to the current and historical implementation of >> title attribute display in browser, discouraging authors from using the >> markup pattern would result in more usable and >> accessible content. > > It is suggested by whom? I'm not sure I follow. I suggest. Providing content as text as against it being hidden in an attribute that requires a mouse to access it, will make the content more usable and accessible. While it is unfortunate that we still have a conformance requirement difference between HTML LS and HTML5 I am satisfied at least that the major conformance checking tool on the web will reflect the HTML5 conformance rule disallowing , and as we are often told, shipping code wins. regards SteveF > > Message: 4 > Date: Wed, 22 Aug 2012 00:43:29 + (UTC) > From: Ian Hickson > To: whatwg > Subject: [whatwg] Conformance checking of missing alternative content > for images > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Fri, 27 Jul 2012, Steve Faulkner wrote: >> >> The spec currently allows img without alt if the title attribute is >> present > > That's a wild over-statement of the case. > > To be precise, the specification requires that the alt attribute be > present, with the exception of some very specific cases. The specific case > where the presence of the title="" attribute is in any way relevant is the > specific case where the image is obtained in some automated fashion > without any associated alternative text (e.g. a Webcam), or because the > page is being generated by a script using user-provided images where the > user did not provide suitable or usable alternative text (e.g. photograph > sharing sites), or because the author does not himself know what the > images represent (e.g. a blind photographer sharing an image on his blog). > > Only in those cases can the alt="" attribute be omitted if the title="" > attribute is instead present with text. In all other cases, elements > in Web pages must have alt="" attributes. > > >> This is problematic for a number of reasons: >> >> 1. One of the functions of alt as implemented is that the text is >> displayed when images are disabled or not available. I ran some tests a >> while back[1] and found that while webkit based browsers display title >> attribute content if images are disabled or not available, IE, Firefox >> and Opera do not. I did a quick recheck and focund the implementations >> have not changed in the 2.5 years since I ran those tests. >> >> 2. title attribute content is commonly displayed as a tooltip that >> appears when a user moves their mouse over an element (in this case an >> img) It is long running issue (14 years or so) that tooltips and thus >> title attribute content is not displayed for keyboard only users. >> Browsers vendors are fully aware of the issue, but as yet there have not >> yet been moves to fix the issue* > > These are violations of the UAAG, and affect far more than images. Any > situation where there is content in a title="" attribute would be an > accessibility problem, if title="" attributes aren't exposed. Either we > should therefore drop the title="" attribute (unlikely to be a practical > option), or we should fix the browsers to expose title="" attributes in > cases where the user is not able to trigger the tooltip. > > I've updated the spec to be clearer about this. > > >> It is suggested that due to the current and historical implementation of >> title attribute display in browser, discouraging authors from using the >> markup pattern would result in more usable and &
Re: [whatwg] Conformance checking of missing alternative content for images
2012-08-22 3:43, Ian Hickson wrote: [...] the > argument is that WYSIWYG editor implementors will be pressured into making their tools output conforming content by people who don't understand the subtlties of this thread, based purely on validator output. To which extent do people pressure WYSIWYG editor implementors into that, who are these people, and is there evidence of the pressure being successful? How often have they made implementors generate alt="" for unknown images, instead of something appropriate like alt="(an image)"? A user converting 100,000 PDFs to HTML isn't going to be entering alternative texts for each image. Such bulk conversions can be useful for many purposes, but the results are not accessible and do not conform to good HTML authoring rules. There is no reason to prevent validators from saying this, in their own way. Take the example of converting one non-HTML document with images to HTML format. Should the result of an automatic converter that generates tags without alt attributes be considered as valid as the result of human conversion with alt attributes added or semi-automatic conversion (where a human is prompted for entering alt texts)? Yucca
[whatwg] Conformance checking of missing alternative content for images
On Fri, 27 Jul 2012, Steve Faulkner wrote: > > The spec currently allows img without alt if the title attribute is > present That's a wild over-statement of the case. To be precise, the specification requires that the alt attribute be present, with the exception of some very specific cases. The specific case where the presence of the title="" attribute is in any way relevant is the specific case where the image is obtained in some automated fashion without any associated alternative text (e.g. a Webcam), or because the page is being generated by a script using user-provided images where the user did not provide suitable or usable alternative text (e.g. photograph sharing sites), or because the author does not himself know what the images represent (e.g. a blind photographer sharing an image on his blog). Only in those cases can the alt="" attribute be omitted if the title="" attribute is instead present with text. In all other cases, elements in Web pages must have alt="" attributes. > This is problematic for a number of reasons: > > 1. One of the functions of alt as implemented is that the text is > displayed when images are disabled or not available. I ran some tests a > while back[1] and found that while webkit based browsers display title > attribute content if images are disabled or not available, IE, Firefox > and Opera do not. I did a quick recheck and focund the implementations > have not changed in the 2.5 years since I ran those tests. > > 2. title attribute content is commonly displayed as a tooltip that > appears when a user moves their mouse over an element (in this case an > img) It is long running issue (14 years or so) that tooltips and thus > title attribute content is not displayed for keyboard only users. > Browsers vendors are fully aware of the issue, but as yet there have not > yet been moves to fix the issue* These are violations of the UAAG, and affect far more than images. Any situation where there is content in a title="" attribute would be an accessibility problem, if title="" attributes aren't exposed. Either we should therefore drop the title="" attribute (unlikely to be a practical option), or we should fix the browsers to expose title="" attributes in cases where the user is not able to trigger the tooltip. I've updated the spec to be clearer about this. > It is suggested that due to the current and historical implementation of > title attribute display in browser, discouraging authors from using the > markup pattern would result in more usable and > accessible content. It is suggested by whom? I'm not sure I follow. > We could address this problem by making changes along these lines: > > Remove the clause in the spec that makes the markup pattern conforming: > > "The title attribute is present and has a non-empty value" This doesn't solve the problem in the general case, so it's not really a solution worth considering. It just papers over a minor case (where the page is in all likelihood not accessible anyway, since the author doesn't know what the image is) while ignoring the much larger issue of title="" not being exposed. On Tue, 31 Jul 2012, Philip Jägenstedt wrote: > > AFAICT there's also no way to read the alt attribute on Opera Mobile. I > don't know what conclusions to draw, but if the situation is the same on > other mobile browsers and they are also unwilling to change, it seems > unwise to recommend using the title attribute to convey important > information. Of course, it would be equally unwise to use any other new > or existing attribute unless mobile browsers expose them in some way. The spec encourages authors to use either title="" or in this situation. I've updated the spec to warn authors that contemporary user agents fail to expose the title="" attribute. On Tue, 31 Jul 2012, Philip Jägenstedt wrote: > > I suppose that if mobile browsers fix Bug 3 *and* fall back to the title > attribute in the absence of an alt attribute then it would be OK to use > title instead of alt, but I'm confused -- is falling back to title a > Good Thing that people want browsers to implement, or is it just a quirk > that some legacy browser had? When there's no alt attribute, if the image can't be rendered, the user agent should display some sort of indicator that there is an image that is not being rendered, and may, if requested by the user, or if so configured, or when required to provide contextual information in response to navigation, provide caption information for the image based on the title="" attribute or (if there's no title="") . On Tue, 31 Jul 2012, Steve Faulkner wrote: > > *Note:* in terms of the accessible name calculation for an img element, > if the image does not have aria-label or an aria-labelledby or an alt > attribute, but does have a title attribute, then the title attribute is > used as the accessible name. From an accessibility API perspective, no > distinction is ind
