Re: HTML5 implementor feedback requested - title attribute accessibility mapping

Hi Chaals, thanks for the feedback.


>> The title attribute as implemented (in all browsers that implement
>> accessibility support) is mapped to the accessible name in all
>> accessibility APIs in all browsers (that implement mapping),
>
>
> We don't do this currently.

It is also true that Opera does not currently complete accessible name
or description calculation support on any platform, so Opera's current
behaviour in regard to the title attribute is not unsurprising.


regards
Stevef








On 20 December 2011 16:43, Charles McCathieNevile <chaals@opera.com> wrote:
> On Mon, 12 Dec 2011 12:54:58 +0100, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>
>> Your feedback on this would be appreciated.
>>
>> The title attribute as implemented (in all browsers that implement
>> accessibility support) is mapped to the accessible name in all
>> accessibility APIs in all browsers (that implement mapping),
>
>
> We don't do this currently.
>
>
>> so in the
>> absence of other labelling mechanisms, all HTML form controls are
>> labelled by the title attribute content if present. The same goes for
>> most other HTML elements. This reality is not reflected in the usage
>> advice in the spec.
>
>
> The spec doesn't seem to match the reality of existing content and advice.
>
>
>> There is a WCAG technique that documents how to use the title
>> attribute to label controls: H65: Using the title attribute to
>> identify form controls when the label element cannot be used
>> http://www.w3.org/TR/WCAG20-TECHS/H65
>>
>> There is another WCAG 2.0 technique that documents how to use the
>> title attribute to identify frame and iframe elements
>> H64: Using the title attribute of the frame and iframe elements
>> http://www.w3.org/TR/WCAG-TECHS/H64.html
>>
>> The HTML5 specification does not provide any advice on how the title
>> attribute content is used (as detailed above).
>> I filed a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
>>
>> the rationale provided by the HTML5 editor for its rejection:
>>
>> "Rationale: If browsers map it in a manner inconsistent with its meaning,
>> that should be fixed."
>
>
> Assuming "that" means "the meaning the specification draft currently
> suggests", the rationale makes sense but rejecting the bug goes counter to
> it.
>
>
>> Do any implementors have any plans to change the current
>> implementation in browsers to match the HTML5 specification meaning?
>>
>> i.e. are there any plans to stop mapping the title attribute to the
>> accessible name in accessibility APIs? So that it does not provide a
>> label for controls and other elements?
>
>
> We're unlikely to do anything new for accessibility that works against what
> other implementations do although we may do new stuff that enhances the
> platform without introducing conflicts. We don't have any strong plans
> either way, but we're likely to follow the other browsers on this.
>
> cheers
>
> Chaals
>
> --
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>    je parle franįais -- hablo espaņol -- jeg kan litt norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com



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

Received on Wednesday, 21 December 2011 10:52:22 UTC