Re: no-title CP - remarks

Steve Faulkner, Thu, 12 May 2011 09:41:45 +0100:
> hi leif, 
> 
> this is incorrect:
> 
>>(Though HTML5-capable screen readers are expected to support ARIA, 
> which would provide access.) 
> 
> 1.The mapping of @title to the accessible name property on any 
> element in accessibility APIs has been standard fallback behaviour 
> pre ARIA.
> 2. In regards to accessibility API mapping it is not the screen 
> reader but the browser that does the mapping and presents content as 
> an accessible name value.

It *is* justified to say that ARIA, which is something HTML5 UAs are 
expected to support, will provide better access to @title. Btw, 
everytime I have talked about non-ARIA, Rich has told me that we are 
defining requirements for HTML5 UAs. So I now try to adopt that 
attitude.

Also, in the CP you state, about screenreaders - and not about 
browsers! - the following: "Access to title attribute information is 
not supported uniformly by screen readers." 

But of course, whether it is the screenreader or the browser that 
fails, is of of course important, and I perhaps am inaccurate there. 
However, the gist of what the CP says is that ARIA's text alternative 
computation section provides systematic access to @title. This is not 
at all hyphothetical - it is a feature of ARIA's text alternative 
computation.

As for what is 'standard fallback' in screenreaders: when I test JAWS 
12 with Internet Explorer version 8, then, whenever @alt is omitted or 
is empty, JAWS does not always present @title. [It - or IE8 - follows 
an undocumented pattern w.r.t. presenting @title.] VoiceOver+Safari, 
OTOH, which does implement ARIA better (AFAIK), does present @title, 
quite systematically.

> your CP states:
> 
> "When @alt is omitted, then - on the positive side - @title is 
> presented instead of the @alt, provided that the user uses an AT 
> which implements ARIA, or provided the user uses a text browser 
> (Lynx/W3m/Links/Elinks) or a Webkit based browser [snip]

> ANY content is capable of being displayed on any browser that 
> supports modern CSS, if the author decides to do it, this is NOT the 
> issue, the issue is whether browsers provide input device independent 
> access to title attribute content, they do not and none have 
> indictaed their intention to do so. Again I find that the text above 
> only serves to obsfucate the argument.

If you want to only focus on 'input device independent access', then I 
think there are several parts of your CP you should axe. E.g. don't 
mention anything about @title troubles in some screen readers. 

Like I have said, I think you overfocus on 'input device independent 
access'. Clearly 'input deviece independent access' is relevant, but 
strictly speaking it is only relevant when the browser does not use 
@title to repair for lack of @alt.

Also, your CP does not say that authors should place content insid @alt 
- it makes no requirement that they do. Instead it says that authors 
should place advicory content in a visual caption element. So you don't 
really focus very much on @alt, as far as I can see. All the focus is 
on the 'input device independent access'. As you stated in the Risks 
section: "Authors will be required to use an element rather than an 
attribute to provide captions."

Btw, the point with focusing on CSS is that generated content can be 
accessed by AT! Previously, CSS was only considered "presentational". 
However generated content in Webkit and Opera is not only 
presentational. (But, when I think about it, it might still be in 
Firefox, so I perhaps should not have mentioned Firefox.) 

To compare @title with "ANY content", is not relevant. Unless you have 
@aria-label in mind, then HTML5/ARIA do not have any relevant authoring 
rules for "ANY content". But HTML5 has some authoring rules for @title, 
even if they are not as specific as for @alt. Firstly @title is 
supposed to be about the element it is attached to. Secondly, it is 
supposed to be advicory. Thirdly, we know from experience that authors 
puts useful info in @title - they often mix @alt and @title up.

A CP which is supposed to "win" should not place anything under the 
table. And should not exaggerate, negatively or positively. It might be 
that I exaggerate on the positive side. However, I see the opposite in 
your CP.

Leif H Silli

Received on Friday, 13 May 2011 13:10:27 UTC