Re: no-title CP - remarks

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.

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 (e.g. desktop browsers Safari, Chrome, mobile browsers
Bolt, Nokia's browser in some Symbian phones etc.) Webkit is more and more
popular, which in theory broadens the support for this kind of @alt repair.
Note, though, that Webkit is known to fail to display @alt at all, unless
the author takes certain CSS
precautions<http://www.456bereastreet.com/archive/200912/safari_webkit_and_alt_text_for_missing_images/>.


In UAs without @title based @alt repair, then Opera, Opera Mini and Opera
Mobile are capable of performing missing @alt repair with help of @title if
the author helps it with generated CSS. But this requires a very conscious
author and it currently isn't a known authoring praxis. Firefox 3 and 4 have
similar possibilities. However, how well it could work in praxis remains to
be seen. Internet Explorer 9 is the only browser of the big ones that
appears to lacks CSS ability to perform @alt repair with help of @title."
i see no good reason to have this information in the CP the main thrust of
the issue is the very practical barrier that use of title presents:
content that is meant to be be available to any user at any time, is only
available to some users some of the time. It does not fulfill its primary
purpose. Providing information about how title does fill the void left by
lack of alt in some browsers only obsfucates the issue.

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.

regards
stevef


On 12 May 2011 04:12, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no>wrote:

> Janina Sajka, Thu, 12 May 2011 01:32:59 +0000:
> > Leif, Steve, and All:
>
> >> http://www.w3.org/html/wg/wiki/ChangeProposals/EnTitle
> >>
> >> Main difference from Steve's prop: a warning instead of an error
> >> message, a different reading of the (browser) facts and other
> >> justifications (plural) for revisiting the issue.
> >>
> > Thank you for this very succinct clarification. [ snip ]
>
> Thanks for those kind words! And for the encouragement to consensus.
>
> I have now made an effort to bring the two CPs closer to each other.
> The CP is located at the same address but now has the following title:
>
>   "@title is only a last resort source for text alternative
>    repair - authors must not rely on such behavior"
>
> where the last part of the sentence is a quote from HTML5.
>
> Main changes:
>
> * I have copied lots of Steve's text into the CP - I hope he is OK with
> that.
> * I added more critical remarks about Webkit.
> * I accept as premise that @title alone should not make the IMG
> conforming.
> * The summary is new.
>
> Compared with Steve's proposal, there is now less difference, however I
> still give weight to author's possibilities to make @title displayed
> via CSS and I point to WAI-ARIA's systematic access to @title when @alt
> is lacking - though I now balance with the fact that most authors would
> never do this. As before, I thus give more positive weight to Webkit's
> behaviour (which seems possible to replicate in Opera and Firefox with
> a little help from the author), but I balance by mentioning Webkit's
> well known problems of displaying @alt properly at all as well as
> expanding on some of the problems described by Steve related to getting
> @title to display when image is not displayed - @title is far from as
> (technically) reliable as @alt.
>
> The CP now, thanks to the things I took from Steve, gives attention to
> both keyboard access and "fallback repair access".
>
> Of course, Steve is welcome to borrow from my CP as well. I feel that
> the CP now gives a true picture of the @title status. But I of course
> open to corrections and changes etc.
>
> 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