Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

On Aug 16, 2009, at 17:51, Sam Ruby wrote:

> It also presumes that invalidating one spec by another is not best  
> practice, something that the current HTML5 draft does in a number of  
> occasions.

HTML 5 overrides past specs, or specs whose maintainers are  
uncooperative. ATAG 2 and HTML 5 are both specs in development, and I  
think cooperation would be good here.

> And the suggestions above (and by that, I mean the whole list: items  
> 1 through 5) would seem like a more credible proposal if you could  
> point to a consolidated place where the current differences between  
> the CG Consensus Resolution and the HTML Working Draft have followed  
> the above procedure.
[...]
> Between the three of you, nobody has provided any feedback on the  
> resolution itself.  Collectively, you are suggesting a burden of  
> proof that you are not ready, willing, and able to meet yourselves[7] 
> [8].

The reason why I formulated my reply the way I did was to carefully  
avoid stepping on the toes of ATAG 2 at step #2. (I'd really like to  
learn more about what the consensus on this point is in the group  
defining ATAG. I have tried to elicit information on this publicly and  
privately over a long period of time but I have failed. Based on  
seemingly conflicting statements on the topic by past and present  
editors of ATAG 2 (sorry, no reference), I suspect the reason why I  
have failed to elicit this information is that there isn't a clear  
consensus, yet.)

However, I can fill in step #2 as an accessibility non-expert based on  
hearsay about step #1, and then evaluate step #3 given my own filling  
in of steps #1 and #2:

My understanding about step #1 is that UAs most often behave like this:
  * The content of non-empty alt attribute is read to the user in  
place if the image.
  * Empty alt (or role=presentation in new clients) cause the  
rendering to be as if the image didn't exist.
  * Absent alt causes the presence of the image to be announced to the  
user.

The case for the tool user providing a text alternative is, I believe,  
completely uncontroversial: The tool should provide a UI for inputting  
the text alternative, and the text should end up as the value of the  
alt attribute.

Based on what I gather from comments praising Dreamweaver and from my  
own reasoning, I think the advice at step #2 should be that an  
authoring application in the situation where its user doesn't supply a  
text alternative must not generate a text alternative (especially not  
from the file name) and must not generate markup that masks the  
existence of the image (empty alt or role=presentation). Therefore, an  
image tag without an alt attribute or a role attribute should be  
generated when the user of the authoring application hasn't  
affirmatively provided a text alternative or an assertion of  
presentationality.

As a matter of language design, I think the absence of the alt  
attribute is a sufficient syntactic signal of its absence. I think  
adding more syntax for affirming its absence (e.g. noalt, missing,  
etc.) is unhelpful.

As for providing a marker for flagging alt autogenerated, the premise  
of such a marker would be that the software operated by the Web user  
could upon consuming such a marker ignore the alt and try to generate  
a better one itself. The problem is that the software operated by the  
Web user can't know if its own heuristic outperforms the heuristic  
used by the authoring app. How would the client software know when to  
second guess the authoring software? Due to this problem, I don't  
support emitting autogenerated text alternatives but then flagging  
them as such.

With those assumptions, here's my feedback on the WAI CG consensus  
(further quotes from the consensus document):
>     * @alt is a very important accessibility attribute (it is  
> supported by all browsers, most authoring tools and is the most well  
> known accessibility technique among authors).

Agreed.

>     * Having @alt "required" in HTML 4.01 raised public awareness of  
> Web accessibility in general.

Agreed, however, the requirement has also caused people to write  
software that puts stuff specifically disapproved by ATAG 2 into alt  
just to satisfy validators.

>     * automatic validators can detect the presence/absence of @alt  
> but in general cannot certify the correctness of the text string.

Agreed.

> Principles underlying the advice below
>
>    1. The working group recommends that HTML5 provide mechanisms for  
> both short and long text alternatives.
>           * These are different concepts with different uses and  
> both should be provided as separate functions. Short descriptions  
> are read automatically when the item is encountered. Long  
> descriptions are read only on user request.

I don't have the right expertise to be able to tell if these are  
appropriate requirements, but I don't have a reason to notably doubt  
these requirements.

>    2. A short text alternative (using one of the mechanisms) should  
> be required for validity but the long description should not be  
> required.

I disagree, because this requirement leads to bogus short text  
alternatives in order to satisfy validators. However, I think it's  
good for validators to have a supplementary mode for reviewing text  
alternatives.

>    3. We recommend continued inclusion of the alt attribute as one  
> of the valid mechanisms to provide short text alternatives.

I agree.

>    4. We recommend aria-labelledby as a second valid mechanism for  
> short text alternatives.

Makes sense.

>    5. We recommend
>           * that HTML5 state that "For guidance on accessibility  
> requirements for text alternatives authors should consult WCAG 2.0."

I think that's a fair informative statement. However, I think it  
wouldn't hurt to provide information on how to meet such requirements,  
because WCAG 2 (the Recommendation), by design, doesn't give such  
advice and the accompanying working group Notes apply to past versions  
of HTML and XHTML and are not as comprehensive on some points as the  
current HTML 5 draft text.

>           * and that HTML should not provide any guidance that  
> conflicts with WCAG.

I agree to the extent "WCAG" means WGAC 2.0 the Recommendation. I  
disagree if WCAG is understood to encompass accompanying informative  
Working Group Notes in such a way that their own applicability  
statements are extrapolated to cover HTML5.

> Specific recommendations regarding Short Text Alternatives
>
> NOTE: These recommendations assume that ARIA features referenced in  
> this document are included in HTML 5.
>
>    1. <img> is only valid when at least one of the following is true:
>           * @alt is present (empty or non-empty) OR
>           * @aria-labelledby is present (non-empty only) OR
>           * the <img> is located within a <figure> that has a non- 
> empty <legend> OR
>           * @role="presentation"

It seems to me that this would lead to software developers programming  
their software to generate an empty alt or role=presentation when a  
text alternative isn't available to the generator software. Assuming  
that this is bad, I think we shouldn't have a requirement that will  
likely lead to such an outcome. (I'm assuming here that having a  
marker for flagging autogenerated text alternatives as having been  
autogenerated poses a new dilemma: how to act on that information.)

That is, I (at least tentatively) disagree with both the WAI CG  
consensus and the current HTML 5 draft here.

>    2. That
>           * the proper use of @role="presentation" be taken from  
> ARIA 1.0

I agree. Further, I think HTML 5 should relax its position on  
presentational markup enough to allow role=presentation. (If the  
stance is that presentational markup is never OK, logically  
role=presentation would always be wrong.)

>           * and that an <img> without a @role attribute is assumed  
> to be the equivalent of <IMG @role="img"> (and would follow the  
> rules in #1 above)

It seems to me that this point isn't precise enough. Surely such  
defaulting only makes sense if the <img> has no role=img ancestor?  
Furthermore, the accessible name calculation seems to need host- 
language-aware special casing here.

>       NOTE: 'Presentation' should not be defined to be broader than  
> what is defined by ARIA

I agree.

>    3. For cases in which it is appropriate for user agents to ignore  
> the presence of an image (e.g. when the image is used for  
> decoration, for formatting, or when the image is invisible), one or  
> both of the following may be used:
>           * @role="presentation"
>           * @alt="" (also see (4))
>
>       INTENT: That it is VALID to use either ROLE and/or ALT="" to  
> mark "presentational" content.

Having role=presentation without alt='' seems backwards-incompatible  
but makes sense on the long term, I guess.

>    4. alt="" WITHOUT an accompanying role="presentation" triggers a  
> non-critical validator warning recommending use of  
> role="presentation" (but @alt="" remains technically valid)

Since we now have normative warnings, I guess this could be added.

>     5. We suggest new mechanisms for short text alternatives (e.g.  
> aria-labelledby, <legend>) should be capable of handling structured  
> content. Our primary concern is that short text alternatives be able  
> to support inline text structure, such as abbreviations, language  
> changes, emphasis, etc.
>
>       RATIONALE: It would be helpful for the short alternative text  
> mechanism to support structured text.

Makes sense.

> Recommendations regarding Long Text Alternatives
>
> NOTE: Long text alternatives go beyond short text alternatives and  
> allow users (at their request) to get detailed information about non- 
> text content.
>
>    1. Long text alternatives (e.g. aria-describedby ) should not be  
> required for validity (though they may be required by WCAG 2.0 for  
> some types of non-text content).
>
>       RATIONALE: A long text alternative is not always required for  
> accessibility. A short text alternative is often sufficient. So a  
> long text alternative should not be required for validity.

Makes sense.

>    2. Mechanisms for long text alternatives should be capable of  
> handling structured content.
>           * Our primary concern with long text alternatives is that  
> they be able to support block and inline text structure, such as  
> abbreviations, language changes, emphasis, tables, headings, etc.  
> However it is not necessarily limited to these and could include  
> rich media types.
>
>       RATIONALE: Current LONGDESC can support structured content.  
> This should not be lost with any new mechanisms.
>    3. Because we are confident that aria-describedby will be  
> supported by assistive technologies at least as well as longdesc  
> when HTML5 becomes a W3C Recommendation:
>           * IF
>                 o aria-describedby is incorporated in HTML5
>                 o and aria-describedby allows pointing to long text  
> alternatives that are off of the page (by pointing to a link on the  
> page)
>           * THEN
>                 o we believe it is acceptable to obsolete longdesc  
> in HTML5.
>
>       RATIONALE: It is important that a long text mechanism exist  
> which is capable of pointing off page. Long descriptions are often  
> too lengthy and detailed to be included on the main page. If aria- 
> describedby can point off page (by pointing to a link on the page)  
> then it would remove any need for continued support of LONGDESC  
> which is not widely used by authors at this time. (NOTE: it is  
> understood that aria-describedby cannot point off page directly.)

I think obsoleting @longdesc and recommending @aria-describedby in its  
stead makes sense.

> Recommendations regarding auto-generated alternative text
>
> We have reached the following consensus concerning "automatically  
> generated" alternative text:
> In order to address both the validity and human generation concerns,  
> we do not oppose the creation of 'autogenerated' and 'missing'  
> attributes where either one of these could be used to make an image  
> that does not have any human-generated text alternatives valid.  
> (Note: It is important that this marker is not included in the  
> alternative text string itself.)"

I don't understand how autogenerated but so flagged text alternatives  
would be helpful, because they create the problem that receiving  
software needs to be able to guess if it should present the  
autogenerated alternative or try to replace it with its own  
autogenerated alternative.

> Use Case 2 (author using a photo sharing site)
>
>    1. author logs into the photo sharing site
>    2. author uses the uploader feature to upload 50 pics of a  
> vacation (XYZ0001.png, XYZ0002.png,..., XYZ0050.png) into an album  
> the author calls "Paris 2009".
>    3. a prompt appears asking the author to write descriptive labels  
> for each image to facilitate text searching and access by people  
> with disabilities.
>    4. the author logs off without adding individual text alternatives.
>    5. the photo sharing site assigns the @alt strings "Photo 1 of 50  
> of album Paris 2009"
>    6. 6. when the author logs back in they still see indicators on  
> the images and/or the album that reminds them that the images are  
> still lacking descriptive labels.


As stated earlier, it seems to me that aria-setsize and aria-posinset  
would be more appropriate here.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 16 August 2009 16:03:59 UTC