[Bug 13651] Missing alt should not be considered conforming in the presence of figcaptions over 50 words in length.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13651

--- Comment #12 from John Foliot <jfoliot@stanford.edu> 2011-08-10 01:50:49 UTC ---
(In reply to comment #11)
> > With regard to this bug, the research and evidence was done and presented.
> 
> The bug report cites evidence that some captions are longer than 50 words, but
> only opines that this is harmful.

So it is your counter-opinion then that alternative text in excess of 50 words
is not harmful, is not a poor user-experience for screen reader users, and
satisfies the needs of non-sighted users appropriately? Perhaps you have
evidence that supports that contrary opinion? Please do share.


> 
> > Are you going to suggest that the editor has more experience using screen
> > readers, and has a better understanding of that user perspective, than
> > someone who is clearly an experienced daily SR user?
> 
> No. But there's a wide chasm between a bug reporter understanding a user
> perspective and us actually solving users' problems, especially when we have
> such extremely limited influence over the system with which the user has
> problems.

First, this is not a "system" issue, this is an authoring and conformance
issue: regardless of which browser or screen reading technology you may be
using, a textual alternative for an image should be "brief" and succinct. 

The @alt attribute is not for verbose descriptions, it is for textual
alternatives to images, a fact reinforced by the fact that we have other
methods and means for providing longer descriptions of images (such as
aria-describedby, <details> and <summary> and @longdesc):

   "It is important to understand that a text alternative provided in the alt
attribute is a replacement for the image, while a short text alternative in the
alt attribute, accompanied by a programmatically associated longer text
alternative, can be a description of the image..."
http://dev.w3.org/html5/alt-techniques/#sec2 

Spending any time at all with WCAG 2 Success Criteria will confirm that in
numerous instances there is an articulated need for short alternatives as well
as long text descriptions (but as well that they are functionally different):

http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/text-equiv-all.html
http://www.w3.org/TR/WCAG20-HTML-TECHS/G95.html
http://www.w3.org/TR/WCAG20-HTML-TECHS/G94.html
http://www.w3.org/TR/WCAG20-HTML-TECHS/G74.html


> 
> > > We shouldn't be trying to obtain and
> > > then disprove a negative proof, we should be trying to provide positive proof
> > > for problems up front.
> > 
> > This is a conformance question, not a user agent issue and to meet a standard
> > of usable, accessible page content, overly verbose ALTERNATIVES to visual page
> > elements have negative consequences. If you or anyone else can prove this to be
> > wrong then please bring forth that proof. 
> 
> Restrictions on authors (especially those requiring them to do additional work)
> should be proven to be truly necessary and plausibly effective.

Conformance reports of success or failure (a method of positive and negative
reinforcement) can have highly effective results - it is in fact the root of
most education curriculum (Pass or Fail) and behavior modification. 
http://en.wikipedia.org/wiki/Behavior_modification

It is in fact this very behavior and methodology that the HTML5 spec is seeking
to use when it obsoletes existing elements
(http://www.w3.org/TR/html5/obsolete.html) - by making "bad" author behavior
trigger a conformance error, the spec seeks to modify such author behavior. If
you are in disagreement with this methodology, then I look forward to your
alternative recommendation on how to affect such change.


> 
> Citations of demonstrations by the "host of affected users" that they require
> short and long alternatives would constitute revelant evidence. Please provide
> them. Descriptions of how they would be used would be especially pertinent.

I'm afraid you have this backwards. 

The Draft Specification seeks to make changes to an existing requirement for
the @alt attribute, in the process breaking backward compatibility. Thus the
onus is on the change proponents to prove that this change does not cause
'harm'. 

We have had a decade of user experience that has suggested and supports the
fact that non-sighted users want and need (when appropriate) both short and
longer textual content with regard to images, and the WebAIM survey of 2009
suggests that fewer than 15% or respondents wanted a verbose (long) textual alt
for images. 
http://webaim.org/projects/screenreadersurvey2/#images 



> 
> > Suggesting that perhaps someday some screen reader might afford the end user
> > the opportunity to undo bad authoring practice is Utopian at best and fosters
> > the creation of problematic content today.
> 
> Requiring authors to generate more metacrap should be our last resort, not our
> first:

I find referring to text alternative to images that non-sighted users cannot
see as "meta-crap" highly offensive and insensitive. If you have such little
regard for the real needs of real users that you can cavalierly dismiss this
need as "meta-crap" then frankly you don't have any real understanding of the
issue and continued debate here is likely pointless.


> 
> I'd restate the problem raised by this bug as follows: users can discover,
> find, or retrieve relevant content (e.g. by reviewing a document, or reviewing
> a list, or by skipping from graphic to graphic) more conveniently if short
> titles label images rather than longer text, even if that text serves an
> equivalent purpose to the image or provides additional information.

It is at the point where it is providing that "additional information" that
authors can inadvertently introduce negative user-experiences. Once again, this
comes down to understanding the difference between a functional alternative and
a detailed description of an image (but then, for someone who considers this
all meta-crap, I'm not too surprised you don't get it)


> How can
> user agents present a short title for images when <figcaption> isn't one and no
> alternative mechanism for labelling the image has been used? (Have I missed
> anything?)

Except that it is not a "How" question any longer, it's an "if" statement: "If"
text inside of <figcaption> is too verbose to act as a functional replacement
for @alt (and it has been conceded that in many instances figcaption can be a
functional replacement), then it should be considered non-conformant unless
@alt text is also provided. The question is not if figcaption can be a possible
stand-in for @alt, but rather when does it cease to be so?


> 
> Janina's examples suggest that user agents could generate decent titles for
> images in <figure> based on the first sentence of their <figcaption>. 

It would be extremely helpful if you could demonstrate that you understand the
difference between alternative text for images, image titles, summaries and
descriptions, as in fact they are all quite different.


> User
> agents already solve similar problems this way elsewhere. For example:
> 
>    * Google use text from a webpage to generate a description for a webpage for
> presentation amidst search results.

That is a summary of the page, it is not a functional alternative to that page.



>    * JAWS reads the first sentence of each paragraph to provide a summary of a
> document.

Again, a summary of the paragraph/page, and not an alternative of that page. 

As well, in both instances they are summations of existing text, and not
functional alternatives to images, so you are comparing potatoes to oranges.


> 
> How is suggesting that such techniques could be expanded to captions more
> "Utopian" than (say) suggesting popular browsers could expose @longdesc via a
> button on their main toolbar?

Because we are talking about authored content, not user interaction or browser
behavior. Once again, do you even understand what the problem here is?


> > If you don't like 50, provide another number. 60? 80? 250? 8,439? For
> > conformance checking, what is the number that you would propose to page
> > authors? And why?
> 
> Neither HTML nor WCAG2 Recommendations constrain labels for UI components or
> content sections with arbitrary word counts.

Both HTML and WCAG require "testable" conformance:

  "WCAG 2.0 success criteria are written as testable statements that are not
technology-specific."
http://www.w3.org/TR/WCAG20/

  "The HTML5 specification will not be considered finished before there are at
least two complete implementations of the specification. A test suite will be
used to measure completeness of the implementations. This approach differs from
previous versions of HTML, where the final specification would typically be
approved by a committee before being actually implemented. The goal of this
change is to ensure that the specification is implementable, and usable by
authors once it is finished."
http://dev.w3.org/html5/html4-differences/#development-model

If you have an alternative suggestion on how to make this testable please speak
up.


> By consulting a human being:
> 
> "All WCAG 2.0 Success Criteria are written as testable criteria for objectively
> determining if content satisfies them. Testing the Success Criteria would
> involve a combination of automated testing and human evaluation. The content
> should be tested by those who understand how people with different types of
> disabilities use the Web."
> 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

Except you snipped off the next section:

"Testing and testable in the context refer to functional testing, that is
verifying that the content functions as expected, or in this case, that it
satisfies the Success Criteria. Although content may satisfy all Success
Criteria, the content may not always be usable by people with a wide variety of
disabilities. Therefore, usability testing is recommended, in addition to the
required functional testing."

Currently in HTML 4/XHTML1 we have a requirement that all images have @alt, and
that @alt be either empty (alt="" silences screen readers, and is functionally
equivalent to aria-role="presentation") or contain a text string. Those are
testable criteria that validators and other testing tools can apply, whilst
having your human being verify that the text alternative is *appropriate* is
also required for true accessibility. 

This is not any different. While an actual word count might seem arbitrary to
you, we none-the-less have the following functional requirement:

 - Images require SHORT text alternatives.

Once again, if you have a better proposal on how to ensure a testable criteria
that ensures that figcaption as a REPLACEMENT FOR (and not supplementary to)
@alt is not too verbose can be constructed, please do speak up. 

Rejecting that there is a need here however is not acceptable.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 10 August 2011 01:50:53 UTC