Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

On 17/08/2009 16:39, Steven Faulkner wrote:
> the AT could just as well support a mode where all images are
> available including those with role="presentation"

It certainly could support a mode that even exposed images with 
"role='presentation'".

It doesn't follow that would be "just as well" (e.g. for meeting Joe's 
use case) as a mode that excluded those images.

I'm hoping "role='presentation'" will be used more specifically than how 
alt="" has been used in practice, such that UAs could distinguish between:

    * images with non-empty text alternatives (e.g. "alt='Sales chart'")
    * images with empty text alternatives (which can mean a variety of 
things in the web corpus even if it has only one conforming use in HTML5)
    * images entirely missing text alternatives
    * images that are definitely decorative (e.g. "role='presentation'" 
or, preferably, "presentational")

Exactly what combination of images a UA chooses to expose in any given 
mode is very much up to the UA.

Currently, the nightly build of Firefox pushes

   <img alt="" src="sales.png">

into MSAA with role equals graphic and name equals null.

Requiring UAs not to push such images into MSAA seems like a significant 
change, so it's worth making sure it /definitely/ helps AT rather than 
hinders them.

You'd also need to make sure that images like:

   <img alt="" title="Sales" src="sales.png">

(or similar sources of text alternatives) were still pushed into MSAA.

 > this could be achieved by accessing the HTML DOM rather than the 
accessibility API's

When access to the raw DOM is provided to AT (which is not required for 
conformance with WAI-ARIA as far as I can tell - perhaps it should be!), 
it certainly could be achieved that way.

But when deciding whether to instruct UAs to treat "<img alt='' ...>" 
the same as "<img alt='' role='presentation'>", the question is does it 
help or hinder AT developers to exclude "<img alt='' ...>" from exposure 
in the accessibility tree?

I've not done any serious AT programming myself, but I had a discussion 
with a commercial screenreader developer a couple years ago and they 
said that extracting information from the IE's DOM API was less 
efficient than extracting information from IE's MSAA API.

Based on that, I think whether these "img" elements should be in the 
tree or out of it depends on how often AT wants to expose their presence 
to end users, compared to other "img" elements with and without 
"role='presentation'". The best way to answer that question may be to 
ask AT developers which subset of images they would prefer included in 
the accessibility tree. Has anyone already performed and (ideally) 
documented that research to a level of detail where it could answer the 
question for my example markup?

Regardless of the answer to that question, I think it would be actively 
harmful for HTML5 checkers to suggest replacing "alt=''" with 
"role='presentation'", even for images that are not a source of repair 
text for controls, since:

1. Only the former works with legacy UAs.
2. Only the former would be usable by current and future UAs (text 
browsers, GUI browsers with images disabled, GUI browsers applying user 
styles, any browser when the image download fails, etc.).

I think HTML5 checkers should only give advice about when to add 
"role='presentation'" to "alt=''" if that can cause the image to be 
treated differently by ATs, since:

1. I don't think teaching authors about language features is a good 
reason to hassle them to add them redundantly.
2. Otherwise, I'm unaware of another use case for "role='presentation'" 
in conforming HTML5. Is there one? If there is a use case elsewhere, 
then that's where the advice should be triggered, not on "img".

Likewise, if HTML5 were to add a "presentational" attribute, I don't 
think authors should be advised to replace "alt" with it, and I don't 
think it should be included at all unless it can cause the image to be 
treated differently by UAs.

--
Benjamin Hawkes-Lewis

Received on Monday, 17 August 2009 18:58:39 UTC