W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

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

From: <bugzilla@jessica.w3.org>
Date: Sun, 07 Aug 2011 13:48:09 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qq3i5-0006jy-HH@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13651

steve faulkner <faulkner.steve@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |faulkner.steve@gmail.com

--- Comment #8 from steve faulkner <faulkner.steve@gmail.com> 2011-08-07 13:48:07 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 7 August 2011 13:48:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 7 August 2011 13:48:20 GMT