RE: Adaptive Image Element Proposal

Anselm Hannemann wrote: 
>
> >
> >Which will be a horrible user-experience (IMHO) if a screen reader
> > user was forced the expanded description every time. This would
> > reduce the amount of longer textual descriptions produced (a bad
> > thing IMO) rather than encourage their creation.
> No, this is a website-creator issue. If he provides such long texts it
> either has a reason (you also can use this responsively for devices not
> displaying images as a text-fallback, so I think this variant is very
> very useful) or he does a bad job.

Hi Anselm,

So, sort-of yes, sort-of no. You are correct in that this longer textual description, provided by the author, *is* there for a reason, and in a responsive-design world a mechanism for choosing that text over the image is something we should keep in mind. 

However, I think you are leaving out an important consideration here, in that you must also think of the user-experience, and the difference between seeing a block of longer text (which you can visually skip over) versus being blind and having to listen to it is significant. It is for this reason that any longer textual description should be offered as a user-choice, and not as a user-forced construct.

See: http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
     http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Requirements 


> Also you already can set this text length into alt-attribute value
> although it's not that charming.

Worse than "not charming", try actively harmful, based upon the reasons stated above. While the current Draft of the HTML5 spec suggests that this is 'correct', the W3C Domain that oversees accessibility (WAI/PFWG) disagrees, and there is an open Issue (31) at the Working Group to address this problem, as well as remove/remediate the bad examples currently in the spec.

As well, there is a real difference between the role that @alt plays (as it maps to the Accessible Name in the Accessibility APIs) and a mechanism that maps to the Accessible Description (again in the Accessibility APIs). Take for example a pie chart that displayed browser user statistics for the month of July 2012.  It would require an Accessible Name:

 Alt="Pie chart: browser user statistics for the month of July 2012"

...and an Accessible Description:

 "The chart shows that the top 5 browsers for July 2012 are "Browser A" at 40%, "Browser B" at 25%, "Browser C" at 15%, "Browser D" at 12% and "Browser E" at 8%"

Note that given the data, this might also be expressed thus:

<table>
  <tr><th>Browser</th><th>Market Share as a percentage</th></tr>
  <tr><td>Browser A</td><td>40%</td></tr>
  <tr><td>Browser B</td><td>25%</td></tr>
(etc.)


>
> So, no accessibility issue here (confirmed to me by an disabled expert),

There are many forms of disability, and an expert deaf user or an expert amputee who cannot use a mouse may not have the insight to understand what the user-experience is for other disabled users.  (I've also been around this particular web-accessibility block a time or two myself).


> just more responsiveness. 
> > (Related question, could/would that text be HTML rich? What if it read,
> > instead:
> Yes, this would be possible. I am not sure what the current draft says here
> but you should be able to set inline-elements here.
> > ... my initial thoughts would be that the answer is "No", for a raft of
> > reasons)
> Can you share your thoughts if there are ones that are true for
> inline-elements? 


So, how would the hyperlink in this example work for *all* users?

<picture> 
   Painting: The Scream by <a href=" http://en.wikipedia.org/wiki/Edvard_Munch">Edvard Munch</a>....

   <img alt="Painting: The Scream by Edvard Munch">
</picture>

* Should/would the link be exposed to sighted users who see the painting "The Scream"? How would it be indicated? *Should* it be indicated?

* What/how would the interaction pattern look if the <picture> itself was wrapped in an anchor tag (<a href=""><picture></picture></a>)? How would the user choose between selecting the 'outer' hyperlink versus the 'inner' hyperlink?

* WCAG 2 has a specific requirement that states: "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)" (http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html) Given that some users navigate their pages without the benefit of a mouse (including non-sighted, screen reader users), it would stand to reason that a hyperlink such as this must be focusable to be activated, but that focus-ability must be present for all keyboard-only users (as we have no way of knowing which of our users is blind or not). How do you see this dichotomy being addressed in a browser?

* If the link was only there "for screen reader users", what of tools that offer both screen magnification and screen reading (ZoomText) for sighted but low-vision users? Where would the tool 'zoom' to? What would it focus on?

* What (if any) potential issues can _you_ think of surrounding the use of a <table> or list constructs that are hidden, but still (sort of) in the DOM tree and available to some users/software configurations. (I already have some ideas, but I fear I am beating you up too much already, which is not my intent.)

At any rate, these are the nature of questions that currently are surfacing around both Issue 204 and Issue 30 within the Working Group, both in regard to the current <img> element, but germane to any discussion about the introduction of a new Adaptive Image Element and short and long textual alternatives. These are complex questions to be sure, and a lot of discussion has taken place already, but to your thoughts that rich-text should be supported here, and your request to my thoughts why not, I hope this is helpful.

Cheers!

JF
---------------
John Foliot
Web Accessibility Specialist
Co-Facilitator, W3C HTML5 Accessibility Task Force (Media)
Co-Founder, Open Web Camp

Received on Friday, 31 August 2012 23:10:47 UTC