RE: HTML-A11Y Task Force Consensus on Issue-204 (Updated)

Edward O'Connor wrote:
> 
> OK, it sounds like you're both open to considering a SHOUD here.
> Tangible progress!
> 
> If we go with a SHOULD for this requirement, and update
> AllowAriaReferHidden to match, do you think we could come to consensus
> on that proposal?
> 

Hi Ted, 

My single concern is that this is a technique that currently *ONLY* works
for users of adaptive technology (screen readers) and currently does nothing
for sighted users who may still want the linked content that is visually
hidden (using @hidden) but programmatically linked using the ARIA technique.




Candidly and frankly, it is well understood by many that this is an attempt
to get beyond perceived 'problems' with @longdesc, and further we're already
seeing implementations of this in the wild: 

http://asurkov.blogspot.co.uk/2012/05/firefox-14-whats-new-for-at-developers
.html 
http://www.paciellogroup.com/blog/2012/05/firefox-14-image-long-description-
via-link-using-aria-describedby/

Emergent concerns are now over how this would actually work in practice (I
get the principle). For example, using this technique, how would the UI
'work' for sighted and non-sighted users?

	<a href="index.html"><img src="logo.png" alt="The XYZ Widget
Company" aria-describedby="logo_description"></a>
   	<a hidden id="logo_description" href="description.html">Our company
logo</a>

Steve Faulkner notes: "When the image has focus the screen reader user can
press enter to activate the link, because a link action showlongdesc is
exposed on the image, it uses the URL from the link referenced via
aria-describedby."

But wait: the 'image focus + enter' in the above example should take the
user to index.html and not description.html - how does the screen reader
choose which link to follow?  And how does the sighted user a) know that
description.html exist, and b) access that content as well?

One goal of HTML5 is to document reality as it is today (and today, at least
one browser is doing exactly what Issue 204 is seeking to address), which is
why (at least I) worked with Cynthia to get to a CP that reflects reality,
but also fought hard to ensure that warning language was present.  Stating
that user-agents (browsers) SHOULD support this, while not also addressing
the user/usability issue at the same time opens the door to a lot of pain
down the road.

Cynthia Shelley wrote:
>
> Building UI for displaying linked hidden content, so that it works for
> *all* users, not only screen-reader users, also requires a lot of
> thought.  I know that some browsers have UI for longdesc, which might
> be reusable, but we're not convinced that UI provides an excellent user
> experience yet.
> 
> We're not even sure which of these approaches will yield a better
> experience, and feel that a lot more work needs to be done before this
> is ready for a MUST requirement.  We do want to leave the door open to
> further development on either accessibility tree or ui-based solutions,
> in the future, but don't feel that it's ready for a MUST requirement at
> this time.  Personally, I'm not even sure about SHOULD, but am open to
> discussion on that point.

+1

If we are to make this a SHOULD requirement, then we need to ensure that
there is also a requirement (somewhere/somehow) that links it to a
requirement that it MUST also be exposed to *all users* in some fashion, and
not just Screen Reader users, and the conflict resolution (error recovery?)
of when the image itself is also a link needs to be clearly thought through
and documented. 

If we cannot get that kind of linkage into the spec, then I would propose
that we go with MAY language at this time instead. This still leaves the
door open for implementers to move forward and refine the user-experience,
but also requires that a fall-back position exist for legacy support.

JF

****************

MAY   
   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)
http://www.ietf.org/rfc/rfc2119.txt

Received on Friday, 25 May 2012 17:05:27 UTC