Re: Mandatory and Important

[reordered a bit]
On 21 Aug 2008, at 8:26 AM, Dave Singer wrote:

>
> We just went through extensive discussion and communication with  
> other groups to work out how to make alt mandatory, and make it  
> clear how to abide by that mandate in a whole host of situations,  
> with examples.

Your editor, at least, give ample evidence of not having understood  
what we told you.  What
you say below suggests you don't either.  We have yet to have had our  
first joint telecon on
these issues.

> I personally do not see a problem with moving the discussion and  
> examples to the WCAG documents, if that group wishes, but I  
> uncomfortable with going backwards, in two senses:
> a) reverting to the lack of clarity in the HTML4 situation, which  
> resulted in alt="" being (ab)used, or alt being omitted, too often  
> (IMHO);
> b) relaxing the formal requirement that alt be present (which is  
> similar to (a)).

My personal opinion is that the HTML spec can subdivide cases for  
author tutelage where
it helps the author.  Working within the framework of WCAG2 SC 1.1.1.

> As far as I can see, the G in WCAG etc. stands for guidelines,  
> guidelines which should be read and interpreted by the writers of  
> specs as well as the writers of web sites.  It's not the WCAG job  
> to make normative requirements in say HTML, it's ours.

That's a question of interpreting the HTML WG charter.  Have you  
asked your chairs for
an interpretation on that?

My personal version on this would be that HTML may refine but must  
not contradict
the guidelines set out in WCAG, ATAG, and UAAG.  If that's not your  
chairs' interpretation,
we have the Hypertext CG and the Domain structure to mediate some  
resolution.

Caveat:  Given that the Team Contact for HTML WG is still unclear  
what 'conformance'
in HTML5 is supposed to be or be for, you can appreciate that we are  
unclear what
you are trying to do in this regard.

I think there is a lot ofroom for constructive but calendar-time- 
consuming clarification,
teasing apart what constraints map to implementation in browsers,  
what constraints
map to constraints checked 100% mechanically in a checking tool, and  
beyond
that what should be interactively checked (including, by title and  
URI, accessibility
checks), and finally what is good practice offered for author  
understanding.

> So, my feeling is that I haven't seen an actual problem with the  
> current text in HTML5, beyond the reasonable recommendation that at  
> some point the text that is more about discussion and examples  
> should probably move somewhere out of the formal spec. (and that  
> 'somewhere else' would ideally be in an accessibility document,  
> probably).

The injunctions that @alt must hold the empty string in 4.7.2.1.5 and  
4.7.2.1 6
are arguably contradicting WCAG because they only rely on the  
parallel text
to be "surrounding" and do not define a pattern based on markup that  
associates
the image and the parallel text.

http://www.w3.org/html/wg/html5/#a-graphical

We would consider this an actual problem with the current text, even  
if you don't.

More explanation is in a recent post
http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0125.html

The example to suppress @alt in the case of redundant icon and text  
in an link
is correct in its effect, but the explanation is defective.  It is  
not the fact
that the icon and text are adjacent, but that they are together in  
the <a> element
forming the link text, and the text already there as text content meets
the requirements for link text.  If the necessary text were adjacent  
but not
in the <a> element, then the other case would apply where the @alt  
should be
populated with suitable link text.  Again, the intent of these clauses
is conformant to WCAG (personal opinion) but the explanation mis-directs
the user to misunderstand the functional requirement.

Here the "association defined in terms of the syntax" expectation is  
met.
Even if this condition were to be met for the cases discussed in  
4.7.2.1.5
and 4.7.2.1.6, a MUST is inappropriate and a SHOULD, or better,  
publication
in a non-normative best practices document such as WCAG Techniques or  
the
author's guide to using HTML5 would be appropriate.

Some terse @alt value in these cases will be a good transitional measure
to handle the many users using AT that just says the @alt value and
doesn't know about figure/legend and all that.

In WAI-ARIA, at least, we _accumulate_ and prioritize @aria-labelledby
and @aria-describedby, not override.  This allows the user to be in
interactive control of accessing more of the related data for  
clarification.
That's more practical than making a MUST of one pattern.

The injection of the curly braces inside the value of @alt would appear
to be an actual problem with the current text.

http://www.w3.org/html/wg/html5/#alt

We haven't seen how it is of any real use to the user or the AT.  It  
adds
either processing burden on the AT to strip the braces or serious  
nuisance
in the spoken audio for the user to listen the TTS announce them.  If  
the
best the author can do is sub-standard, but better than nothing: just  
do it;
don't apologize.

Is there any evidence from AT builders that they feel the distinction
made by the curly braces would be valuable enough in tuning the user
experience that they would argue for the inclusion of the braces?

Al
/me (personal opinions)

> -- 
> David Singer
> Apple/QuickTime
>

Received on Thursday, 21 August 2008 15:06:49 UTC