Re: ALT issue redux

On 1 Feb 2008, at 9:28 AM, Laura Carlson wrote:
>
> Thank you very much, for moving the ALT issue forward on the the
> Protocols and Formats WG's agenda.

** summary

I think that a better way to frame the argument is something like:

<reasoning>

1.  By the principles, HTML5 wants to support accessibility

2.  By their charters, WAI groups (here WCAG) are the go-to
experts in matters of accessibility

3.  WCAG requires @alt (WCAG1) or the function that in HTML4
is provided by @alt (WCAG2)  [editorial note -- add links]

4.  By the principles, if it 'tain't broke, don't fix it.

5.  Conclusion:  barring the introduction of three fresh good
reasons for a change, the failure of the HTML5 draft to make
@alt on <img> an across-the-board requirement (even if sometimes
it has the value of &quot;&quot;) is a bug.  Or do you have
reasons?

</reasoning>

Does this work for you?

** long form, inline responses

On 1 Feb 2008, at 9:28 AM, Laura Carlson wrote:

>
> Thank you very much, for moving the ALT issue forward on the the
> Protocols and Formats WG's agenda.

Sorry the response to your original query has been a long
time coming.

> On the process point, PFWG may want to consider that WAI is the W3C
> authority on accessibility; not HTML5.

Definitely, WAI are the experts on accessibility and HTML the
experts on HTML.  For the division of labor between format and
best practice in promoting accessible HTML, the experts need
to work together and listen to one another.

Do you consider that the most recent draft response makes this
point adequately?

<quote
cite="http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/0070.html">

WCAG WG is chartered to set Accessibility guidelines and HTML
WG is not; so HTML5 should be careful to create features that support
WCAG and describe their use in ways that conform to WCAG.

</quote>


> HTML5 must support WCAG.

That statement sounds obvious enough.  On the other
hand there are many ways HTML can 'support' WCAG,
and the devil is in the details.

In this conversation we should look more closely at what the kinds
of 'support' that may come from HTML5, and how W3C decides what
support it *will* provide.

W3C Process doesn't really set out how much weight must be given
to existing Recommendations by new Recommendations.  Clearly the
desire is to make them 100% cooperative, but the mapping is not
trivial and the performance to date is mixed.

Since by the Principles propounded by the HTML Working Group
they *want* to support accessibility, let's build on that
and find an answer to *how* HTML5 supports accessibility
that works.

> Under both WCAG1 and WCAG2, text alternatives
> for all <img> elements is a "priority 1" (respectively, "level 1"). To
> support accessibility, HTML5 must require what is necessary to
> implement WCAG.

Not necessarily.  One could also consider as support
a format that defines the necessary structures, but
does not enforce their use.  The failure of the format
to duplicate the WCAG rule does not in and of itself
contradict the rule.

[separation added.]
> According to WCAG alt is required.

In terms of WCAG1 that is true.

In terms of WCAG2 a text alternative is required.  The
format specifics have been removed from the success criterion.
The difference matters.

In looking toward HTML5 which may take longer to finalize that
even WCAG2, it is important to look at the trend, the nature
of the differences between WCAG1 and WCAG2.

> Omitting the alt attribute for critical content contradicts WCAG and
> ATAG.

agreed

> If HTML5 doesn't consider this important enough to require, it
> might as well be saying WCAG is not really required either.

I don't follow this escalation at all.

The HTML5 draft is clear that, at a moral level, the critical
content *should* have its text alternate, in the @alt attribute.

When they say "none may be available, or obvious," the narrative
discussion suggests a division of labor where the photo-sharing
site provides the markup and the public provides the image
content.

It doesn't matter much whether it's a format rule or a WCAG
rule that has been violated; what is going to affect public
behavior is things like:

Will the photo sharing portal refuse to share the pictures
that don't have text alternatives?  I doubt it.

Will the browsers of the grandparents refuse to display the
baby's picture because there is no text alternative?  I doubt it.

If not, what will happen and when?

The question in terms of deployment is "what is going to happen
to you or your content if you violate this rule?"  It's not
a question of "is it a language rule?" or "is it an accessibility
rule?" but "what is going to happen?"

Josh and I would seem to be agreed that "refuse to process
such a page in the browser" is justified for a critical-content
image that is lacking @alt.

The problem with the immediate section about

<q>A key part of the content that doesn't have an obvious textual
alternative</q>

.. is the casual, colloquial way it is written.  It neither
meets the need of software developers for a crisp rule they
can program to, and at the same time it irritates access
advocates by allowing the inference that it disagrees with
the accessibility Recommendations.

> In addition the HTMLWG's own Design Principles state:
> "Design features to be accessible to users with disabilities. Access
> by everyone regardless of ability is essential. This does not mean
> that features should be omitted entirely if not all users can make
> full use of them, but alternate mechanisms should be provided. The
> image in an img may not be visible to blind users, but that is a
> reason to provide alternate text, not to leave out images." [1]
>
> [1] http://dev.w3.org/html5/html-design-principles/ 
> Overview.html#accessibility

In terms of the Principles, one shouldn't overlook the "evolution
not revolution" idea.  @alt as a required attribute is the status
quo.  HTML WG has a stated preference to let sleeping dogs lie
unless there is a distinct good reason to change things.  So there
are two stated preferences of HTML WG that would support keeping
html5:img.alt as a required attribute.

But that's not an accessibility requirement.  The accessibility
requirement is, as said in WCAG2 that there be a text alternative.

HTML5 seems to be on track to tolerate WAI-ARIA markup mixed in with
the HTML5 markup.  Authors could meet the WCAG2 requirement with
@aria-labelledby and @aria-describedby in a host language that
doesn't have @alt or @longdesc.  I am not advocating this change.
But in terms of the feasible range of ways that HTML5 can support
authors in meeting WCAG, even that is technically feasible.

We need to look at the use cases that @alt handles badly or not
at all, figure out how we are going to meet WCAG for those use
cases, and then come back to see how the format spec across the
board, including but not limited to the @alt attribute, supports the
requirements that are set out in WCAG.

I think that a better way to frame the argument is something like:

1.  By the principles, HTML5 wants to support accessibility

2.  By their charters, WAI groups (here WCAG) are the go-to
experts in matters of accessibility

3.  WCAG requires @alt (WCAG1) or the function that in HTML4
is provided by @alt (WCAG2)  [editorial note -- add links]

4.  By the principles, if it 'tain't broke, don't fix it.

5.  Conclusion:  barring the introduction of three fresh good
reasons for a change, the failure of the HTML5 draft to make
@alt on <img> an across-the-board requirement (even if sometimes
it has the value of &quot;&quot;) is a bug.  Or do you have
reasons?

Does this work for you?

Al


> Best Regards,
> Laura
>
> -- 
> Laura L. Carlson
>

Received on Monday, 4 February 2008 19:24:32 UTC