mass-moved component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: There's nothing wrong with verbose alternative text. Pictures, we are told, are worth a thousand words; textual alternatives of that length are not out of the question. There is no usability problem here since an AT can just provide a way for the user to signal that it should move on to something more interesting.

(In reply to comment #2)
> EDITOR'S RESPONSE: 
> Status: Rejected
> Change Description: no spec change
> Rationale: There's nothing wrong with verbose alternative text.

Please provide proof of this statement.

> Pictures, we
> are told, are worth a thousand words; textual alternatives of that length are
> not out of the question.

This is incorrect.

Sufficient Techniques for 1.1.1 - Non-text Content:

Situation A: If a short description can serve the same purpose and present the same information as the non-text content:

G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content using a short text alternative technique listed below 
Situation B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram):

G95: Providing short text alternatives that provide a brief description of the non-text content using a short text alternative technique listed below AND one of the following techniques for long description: 

     G92: Providing long description for non-text content that serves the same purpose and presents the same information using a long text alternative technique listed below 

     G74: Providing a long description in text near the non-text content, with a reference to the location of the long description in the short description 

     G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content

http://www.w3.org/WAI/WCAG20/quickref/#text-equiv 


> There is no usability problem here

Please provide proof of this statement.

> since an AT can
> just provide a way for the user to signal that it should move on to something
> more interesting.

Please provide proof of this statement.

TrackerIssue

(In reply to comment #3)

With apologies, an important line break was missed in the previous response. It should have read:

Situation A: If a short description can serve the same purpose and present the
same information as the non-text content:

G94: Providing short text alternative for non-text content that serves the same
purpose and presents the same information as the non-text content using a short
text alternative technique listed below

 
Situation B: If a short description can not serve the same purpose and present
the same information as the non-text content (e.g., a chart or diagram):

G95: Providing short text alternatives that provide a brief description of the
non-text content using a short text alternative technique listed below AND one
of the following techniques for long description: 

     G92: Providing long description for non-text content that serves the same
purpose and presents the same information using a long text alternative
technique listed below 

     G74: Providing a long description in text near the non-text content, with
a reference to the location of the long description in the short description 

     G73: Providing a long description in another location with a link to it
that is immediately adjacent to the non-text content

(In reply to comment #2)
> EDITOR'S RESPONSE:

> Change Description: no spec change
> Rationale: There's nothing wrong with verbose alternative text. Pictures, we
> are told, are worth a thousand words; textual alternatives of that length are
> not out of the question. 

Would that not require a @longdesc or similar?

> There is no usability problem here since an AT can
> just provide a way for the user to signal that it should move on to something
> more interesting.

Thats just not true as it is a little cart before the horse, as the spec should be clear where either terse and/or verbose descriptions are required and give an overview of the mechanisms available to achieve either. Also considering that current AT doesn't support <figcaption> (never mind legacy agents) care should be taken in HTML5 to understand and support real world usage and user experience.

(In reply to comment #3)
> (In reply to comment #2)
> > EDITOR'S RESPONSE: 
> > Status: Rejected
> > Change Description: no spec change
> > Rationale: There's nothing wrong with verbose alternative text.
> 
> Please provide proof of this statement.

Surely the onus of demonstrating that problems exist needs to be on we who suggest changes to the draft?

> > Pictures, we
> > are told, are worth a thousand words; textual alternatives of that length are
> > not out of the question.
> 
> This is incorrect.
> 
> Sufficient Techniques for 1.1.1 - Non-text Content:

[snip]

> http://www.w3.org/WAI/WCAG20/quickref/#text-equiv 

You're citing documents that provide neither a rationale for dividing text alternatives into short and long nor a way to determine whether "a thousand words" is too long to be a short alternative. That citation does not support your claim that what Ian is saying is "incorrect".

(In passing, as these documents are not part of the WCAG2 Recommendation, they don't have conformance implications either.)

> > There is no usability problem here
> 
> Please provide proof of this statement.

Again, such proofs need to be provided by we who suggest changes to the draft?

> > since an AT can
> > just provide a way for the user to signal that it should move on to something
> > more interesting.
> 
> Please provide proof of this statement.

Consider the case where the user is consuming the content linearly. <figure> will be mapped to the accessibility tree. Future AT can provide commands such as "Skip Figure" to move the point of regard past the <figure> element. For users who want to skip automatically, AT could be configured to read up to an arbitrary word/sentence limit, provide a "Continues" cue, and then skip the rest of the <figure>. Even today JAWS has a "Next Paragraph" command that would either accelerate progress through the text alternative or skip the user beyond it:

   http://www.freedomscientific.com/doccenter/archives/training/JAWSKeystrokes.htm

Consider the case where the user is consuming the content discontinuously, jumping between <img> element, and the AT reads the alternative text for an <img> from <figcaption>. JAWS already provides commands for jumping between graphics, listing graphics, skipping to the next element, skipping to the next different element, and skipping to the next element of the same type. Again, one could build an AT that only reads up to an arbitrary word/sentence limit by default.

So in both scenarios the user would have a way to signal as Ian suggests. With some AT, an approximation of that capability exists today.

(In reply to comment #0)

> Missing alt should not be considered conforming in the presence of
> figcaptions over 50 words in length, except where the base language is
> that of an agglutinative language [3], in which case the threshold for
> considering missing alt non-conforming in the presence of figcaption
> should be figcaptions of over 20 words in length.

This seems to be an entirely arbitrary conformance condition. If enacted it would mean we'd be in the bizarre situation where an image without an alt attribute but with a figcaption 51 words long is non-conforming, but an image with an alt attribute 51 words (or 5000 words) long is conforming. 

It also appears to be sub-optimal to suggest to authors that a short text alternative 50 words long is accessible, but if it's 51 words long it is inaccessible. It seems to me like the kind of thing authors would regard as silly and just ignore; clearly there's no hard and fast rule here.

If length of text alternatives is a serious issue, WCAG would appear to be the best place to provide guidance to authors, not syntax conformance checkers.

The page John linked above also includes an Advisory Techniques section and the second bullet point is "Keeping short descriptions short (future link)." So presumably WAI will provide authoring advice on this issue at some point in the future. 

(FWIW I don't think UAs will suddenly become magically incapable of providing a way for users to skip over lumps of text in the future, but can't prove it.)

(In reply to comment #6)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > EDITOR'S RESPONSE: 
> > > Status: Rejected
> > > Change Description: no spec change
> > > Rationale: There's nothing wrong with verbose alternative text.
> > 
> > Please provide proof of this statement.
> 
> Surely the onus of demonstrating that problems exist needs to be on we who
> suggest changes to the draft?
> 
> > > Pictures, we
> > > are told, are worth a thousand words; textual alternatives of that length are
> > > not out of the question.
> > 
> > This is incorrect.
> > 
> > Sufficient Techniques for 1.1.1 - Non-text Content:
> 
> [snip]
> 
> > http://www.w3.org/WAI/WCAG20/quickref/#text-equiv 
> 
> You're citing documents that provide neither a rationale for dividing text
> alternatives into short and long nor a way to determine whether "a thousand
> words" is too long to be a short alternative. That citation does not support
> your claim that what Ian is saying is "incorrect".
> 
> (In passing, as these documents are not part of the WCAG2 Recommendation, they
> don't have conformance implications either.)
> 
> > > There is no usability problem here
> > 
> > Please provide proof of this statement.
> 
> Again, such proofs need to be provided by we who suggest changes to the draft?
> 
> > > since an AT can
> > > just provide a way for the user to signal that it should move on to something
> > > more interesting.
> > 
> > Please provide proof of this statement.
> 
> Consider the case where the user is consuming the content linearly. <figure>
> will be mapped to the accessibility tree. Future AT can provide commands such
> as "Skip Figure" to move the point of regard past the <figure> element. For
> users who want to skip automatically, AT could be configured to read up to an
> arbitrary word/sentence limit, provide a "Continues" cue, and then skip the
> rest of the <figure>. Even today JAWS has a "Next Paragraph" command that would
> either accelerate progress through the text alternative or skip the user beyond
> it:
> 
>   
> http://www.freedomscientific.com/doccenter/archives/training/JAWSKeystrokes.htm
> 
> Consider the case where the user is consuming the content discontinuously,
> jumping between <img> element, and the AT reads the alternative text for an
> <img> from <figcaption>. JAWS already provides commands for jumping between
> graphics, listing graphics, skipping to the next element, skipping to the next
> different element, and skipping to the next element of the same type. Again,
> one could build an AT that only reads up to an arbitrary word/sentence limit by
> default.
> 
> So in both scenarios the user would have a way to signal as Ian suggests. With
> some AT, an approximation of that capability exists today.


 >Surely the onus of demonstrating that problems exist needs to be on we who
>suggest changes to the draft?

This assumes that the draft is correct, it saves time to ask for and have provided evidence or reasoning otherwise the bug may be escalated because the editor expects the bug reporter to accept the editors word as authoritative without evidence. If this does occur  then the information will be required to defend what's in the spec.

(In reply to comment #8)
>  >Surely the onus of demonstrating that problems exist needs to be on we who
> >suggest changes to the draft?
> 
> This assumes that the draft is correct,

I think we must assume editors' drafts are "correct" (i.e. does not cause problems) until problems are substantiated. Anything else would be chaos.

> it saves time to ask for and have provided evidence or reasoning 

On the contrary, I think it's a waste of time to ask editors to prove unsubstantiated problems do not exist. 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.

> otherwise the bug may be escalated because the
> editor expects the bug reporter to accept the editors word as authoritative
> without evidence. 

Failure to provide evidence of a problem in the first place almost guarantees such escalation, just as software bug reports that do not provide steps to reproduce a problem are unlikely to be fixed:

https://developer.mozilla.org/en/Bug_writing_guidelines

> If this does occur  then the information will be required to
> defend what's in the spec.

Effective change proposals, like effective bug reports, give evidence for problems.

Where is the positive evidence that a 50-word text alternative is required but a 51-word text alternatives is intrinsically not "much more verbose than what is useful or appropriate" or "too distracting"?

What is the rationale for overloading text summaries that could be performed by AT onto authors:

http://www.freedomscientific.com/Training/Surfs-up/Skim_Reading.htm

What is the rationale that such summarisation must be performed by adding text to "alt" rather than by using "aria-labelled" and "aria-describedby" to point at parts of the <figcaption>?

(In reply to comment #9)
> 
> I think we must assume editors' drafts are "correct" (i.e. does not cause
> problems) until problems are substantiated. Anything else would be chaos.

With all due respect, your opinion here, and it *is* just an opinion, is not universally shared. When it comes to understanding the requirements of users with disabilities, many feel that the editor has an extremely poor track-record of understanding and delivering acceptable solutions.

With regard to this bug, the research and evidence was done and presented. It is now incumbent on the editor to address those points with a response more substantial than "WONTFIX" and "there is nothing wrong..." Says who? The editor? Why should his opinion hold the day, especially when this bug was filed by a self-identified daily user of screen reading technology? 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?


> 
> > it saves time to ask for and have provided evidence or reasoning 
> 
> On the contrary, I think it's a waste of time to ask editors to prove
> unsubstantiated problems do not exist.

Except that proof has been submitted that there is a possibility of problems, so the problem has been substantiated. 


> 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. 

You might wish to argue that the number 50 is arbitrary, and that it should be 40 or 60 - fine, bring forth that argument as well - however that line of pursuit in no way dismisses the fact that at some point "too much" is indeed too much: the basic premise of this bug is that overly verbose ALTERNATIVES to images is harmful and unfriendly to non-sighted users.

WCAG, WAI, PF and a host of affected users have repeatedly advocated for, requested, and demonstrated that users of Screen Readers (and not "AT", which also encompasses solutions such as screen magnifiers, alternative switching devices, speech to text technology, etc.) require both short *and* expanded textual descriptions for complex images. This requirement is not a binary either/or requirement, but rather a compound short AND (when appropriate) long textual equivalents to in-page images requirement. 

Before sighted users and authors can dismiss this requirement, it is incumbent on them to disprove this fact. 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.

The bottom line here is that an image with a "thousand words" of text associated to it does not have a textual alternative, it has a textual description. If you, the editor or others cannot understand that difference, then no amount of "proof" will seem to address your position. 


> 
> > otherwise the bug may be escalated because the
> > editor expects the bug reporter to accept the editors word as authoritative
> > without evidence. 
> 
> Failure to provide evidence of a problem in the first place almost guarantees
> such escalation, 

I have already tagged this bug with TrackerIssue, so it is being (one hopes) escalated.


> 
> > If this does occur  then the information will be required to
> > defend what's in the spec.
> 
> Effective change proposals, like effective bug reports, give evidence for
> problems.

Correct, and so it will be the responsibility of the editor or others to prove that images do not require both terse and (when appropriate) longer texts: that this *is* a binary issue and not a compound requirement. Can *you* prove that Ben? Can you prove that an overly long text track does not as some point become an onerous and unfriendly alternative to an image?

> 
> Where is the positive evidence that a 50-word text alternative is required but
> a 51-word text alternatives is intrinsically not "much more verbose than what
> is useful or appropriate" or "too distracting"?

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?


> 
> What is the rationale that such summarisation must be performed by adding text
> to "alt" rather than by using "aria-labelled" and "aria-describedby" to point
> at parts of the <figcaption>?

While this is a good suggestion, how will conformance checkers know that this *may* be appropriate? 

Or are you now suggesting that when authors use figcaption as a replacement for @alt that they must ALSO use one of either "aria-labelled" and/or "aria-describedby"? If that is the case, then a change must still be submitted to the current draft to modify this. Are you prepared to write that Change Proposal Ben?

(In reply to comment #10)
> When it comes to understanding the requirements of users
> with disabilities, many feel that the editor has an extremely poor track-record
> of understanding and delivering acceptable solutions.

So? We wouldn't want editors to prohibit accessibility techniques or drop accessibility features based on unsubstantiated performance problems because they don't know much about performance.

> 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.

> 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.

> > 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.

> You might wish to argue that the number 50 is arbitrary, and that it should be
> 40 or 60 - fine, bring forth that argument as well - however that line of
> pursuit in no way dismisses the fact that at some point "too much" is indeed
> too much:

It suggests that "too much" might vary from case-to-case or user-to-user, so arbitrary limits are inappropriate.

> WCAG, WAI, PF and a host of affected users have repeatedly advocated for,
> requested, and demonstrated that users of Screen Readers (and not "AT", which
> also encompasses solutions such as screen magnifiers, alternative switching
> devices, speech to text technology, etc.) require both short *and* expanded
> textual descriptions for complex images.

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.

> 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:

    http://www.well.com/~doctorow/metacrap.htm

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. 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?)

Janina's examples suggest that user agents could generate decent titles for images in <figure> based on the first sentence of their <figcaption>. 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.
   * JAWS reads the first sentence of each paragraph to provide a summary of a document.

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?

In the rare case where authors provide better titles, the draft provides several features (@aria-label, <details>, and more controversially @alt and @title) that allow them to do so. This is similar to how authors can provide better descriptions for webpages using <meta name="description">.

We don't need to require them to do so in every case.

> Can you prove that an overly long text track does not as some point become
> an onerous and unfriendly alternative to an image?

By definition, "overly long text" is unfriendly to anyone.

> > Where is the positive evidence that a 50-word text alternative is required but
> > a 51-word text alternatives is intrinsically not "much more verbose than what
> > is useful or appropriate" or "too distracting"?
> 
> 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.

Proposing a particular number as anything other than an informative guideline is silly and any number high enough not to be too arbitrary (say 500 words?) would be too high for Janina's examples.

It's particularly absurd to impose length restrictions here when we don't have length restrictions on @alt itself.

> > What is the rationale that such summarisation must be performed by adding text
> > to "alt" rather than by using "aria-labelled" and "aria-describedby" to point
> > at parts of the <figcaption>?
> 
> While this is a good suggestion, how will conformance checkers know that this
> *may* be appropriate?

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

> Or are you now suggesting that when authors use figcaption as a replacement for
> @alt that they must ALSO use one of either "aria-labelled" and/or
> "aria-describedby"?

No.

(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.

(In reply to comment #12)
> 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?

Concision in all text is better.

> Perhaps you have evidence that supports that contrary opinion?

A claim that 50 words is good and 51 words is bad would be nonsensical, since words are not equal. Some words convey more information than other words. Some languages need fewer words to convey the same information, because they combine words to make new words or use inflection in place of parts of speech. Some words have more syllables than other words, so users will have to listen longer. Some words have more characters than other words, so users will have to braille longer. You cannot draw strong correlations between the information conveyed by a word, its number of syllables, and its number of characters. So word count is not a reliable limit on information density, listening time, or braille time, all of which one would aim to minimize for a short text alternative.

Previous literature, included that cited by the bug report, makes a wide variety of recommendations about @alt text length, few of them consistent with a 50 word threshold:

   * http://www.cs.tut.fi/~jkorpela/html/alt.html (50 characters, based on @alt display problems)
   * http://www.washington.edu/accessit/print.html?ID=1257 (125 characters, based on a bug in JAWS 6)
   * http://joeclark.org/book/sashay/serialization/Chapter06.html (1,024 characters, based on @alt display problems)
   * http://www.w3.org/WAI/GL/WCAG20/tests/test3.html (100 words, or higher if the human checker judges it appropriate)
   * http://itl.uconn.edu/idd/wai/html/multimedia.html (50 words)
   * http://www.accessibletech.org/access_articles/webinfo/altAttribute.php (151 characters, primarily based on @alt display problems)
   * http://www.ok.gov/abletech/IT_Accessibility/webtips.html (around 100 characters)
   * http://www.w3.org/TR/html-alt-techniques/#m5 (75-100 characters or 1-2 sentences)
   * http://lists.w3.org/Archives/Public/public-html-a11y/2011Aug/0011.html (250 or 300 characters)

In the absence of positive evidence otherwise, we can see that 50 words is an arbitrary choice not a magic metric that divides helpful from harmful text alternatives.

> > 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. 

By "system" I did not mean the user's individual hardware and software setup, but rather the ecosystem that constitutes the Web, the people who consume and produce content on the Web, the tools they use to do so, and the people that develop those tools.

> > 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.

Author conformance requirements are primarily intended to help authors use markup that does what they want it to, not as some sort of ,control mechanism:

   http://dev.w3.org/html5/spec/introduction.html#conformance-requirements-for-authors

> The Draft Specification seeks to make changes to an existing requirement for
> the @alt attribute, in the process breaking backward compatibility.

A 50 word limit on <figcaption> would not fix backwards compatibility of new content with old user agents.

> Thus the onus is on the change proponents to prove that this change does not cause
> 'harm'. 

The HTML WG process does not require the existing draft to prove its differences from HTML4 do 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

Is this the "demonstrations" by a "host of affected users" you were referring to?

Although questionable, this suggestive evidence would still have strengthened the original bug report. It's a shame it was not provided up front.

> > > 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.

You misunderstand the link. When they're accurate, hidden text alternatives and other metadata are a good thing. Requiring people to add metadata guarantees you will get some bad metadata (metacrap). Where data is really needed, a solution is to make machines generate data - where possible. Sometimes it's inevitable that we need people to add metadata. We should try and work out if this is one of those situations or not. It looks to me like it might be a situation where we can at least let machines generate the data some of the time, so we should investigate that possibility before trying to solve it by making more work for authors through a conformance requirement. That approach that will fail a lot of the time, and thus fail to address the systemic problem. For example, @alt is missing on only two out of ten <img> elements, despite being required by HTML4. (Never mind that many @alt values are entirely incorrect.)

http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img

> > 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)

"Functional alternative" is not WCAG terminology, but assuming by this you mean text that serves an equivalent purpose (which is WCAG terminology), then such text may be longer than 50 words.

The Understanding document for the equivalent purpose success criterion, while merely advisory, is quite explicit here when it says "If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)".

http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html

If, in such a case, a short text alternative *itself* was considered to serve an equivalent purpose, then authors could meet the success criterion by providing a short text alternative and the effect of the criterion wouldn't match its intent "to make information conveyed by non-text content accessible through the use of a text alternative". This was in fact the case with HTML4 conformance where @alt was required but text that served an equivalent purpose was not.

(That HTML5 does require that there be available text that conveys the same information as images, in accordance with that intent, is a virtue of the current draft, even if the ways it proposes this text be made available are controversial.)

> > 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?

I'm describing an end-user problem, not some point of conformance that it is hoped will indirectly address that problem. If we avoid conflating problems and solutions, we stand a better chance of picking an optimal solution.

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

Adding a 50-word limit on <figcaption> before requiring an @alt doesn't do anything to ensure images have text that serves an equivalent purpose. The point of this bug is to provide a short text alternative not text serving an equivalent purpose.

Given that we have mechanisms to extract the first sentence from text, it seems a machine can easily provide some short text given a long <figcaption> and authors have the tools to override such machine-provided text. Such text is liable to be a figure title in both cases, since otherwise it would not work as a good label when the document is being navigated non-linearly - which is the only purpose of the short text in this case. (Since users consuming the document linearly will have already heard the whole <figcaption>, an additional @alt that duplicates information in the <figcaption> will be a brief annoyance.)

> > 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.

Some user needs can be met by user agents without additional authorial effort. Maybe this is one of them. So I still don't understand your notion that this is Utopian.

> > > 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:
> 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.

Machine-testable is only a subset of "testable". We do not need to adopt bad machine-testable conformance criteria in lieu of better human-testable conformance criteria.

> 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.

_If_ it's agreed that end-users need short text alternatives (a requirement that is *additional* to WCAG2), then we can require that if the image has a programmatically associated text alternative and the first sentence of that alternative would not be suitable as a short text alternative, the author must use a mechanism to supply a short text alternative.

Conformance checkers to present images with their short text alternative and long text alternative, allowing humans to test the text alternatives are appropriate.

A test suite for the accessibility API mapping suggestions might verify that the short text alternative (whether implied or explicit) is exposed as accName or an equivalent feature in another language. It would be a good idea for the mapping document to specify how to extract a first sentence to promote interoperability.

Assuming that the intent was for this bug to be tagged 'TrackerRequest', not 'TrackerIssue'.

(In reply to comment #14)
> Assuming that the intent was for this bug to be tagged 'TrackerRequest', not
> 'TrackerIssue'.

Can somebody clear up what is the current state of this?  Is the intent to present new information causing an existing issue to be reopened (just a guess: perhaps issue 31?).  Or perhaps the intent is to create a new issue?

If the latter, please suggest title and text for the tracker issue, as described in the resolution.

(In reply to comment #15)
> If the latter, please suggest title and text for the tracker issue, as
> described in the resolution.

From Janina's reply:
http://lists.w3.org/Archives/Public/public-html-a11y/2012Jan/0150.html

Suggested Title: Missing alt should not be considered conforming in  the presence of figcaptions over 50 words in length

Suggested Summary: While clearly arbitrary as to the particular number of words, fig-captions of greater length are reliably not acceptable alternatives for missing alt, where fig-captions of but a few words generally are. 

/paulc

https://www.w3.org/html/wg/tracker/issues/202

Discussed in HTML Accessibility TF Meeting on 13 Feb 2014
http://www.w3.org/2014/02/13-html-a11y-minutes.html#item10

RESOLVED to consider for HTML 5.1 More info needed

Moved to HTML a11y Task Force component on 08 MAR 2014 for additional info.