Re: no-title CP - remarks

Hi Leif, thanks for your feedback,

I will not be making any substantive chnages to the CP.

What you view as negatitvity, I see as practical considerations in respect
to current and historical support for the title attribute and the browser
vendors not providing any evidence that the story will change in the near
future.

The validation requirements for HTML5 have already been implemented in an
experiemental build by mike smith and will likely by public in the near
future. I do not want to see the relaxing of HTML5 validation requirements
NOW based on the possibility of support at some unkown time.


regards stevef

On 13 May 2011 14:09, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no>wrote:

> 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
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html