RE: Bug: Firefox Accessibility Inspector reports placeholder attribute as eligible for accessible name

> on the other hand, would say the name calculation should take into account placeholder (as a last resort, which it currently is, and as an additional accessible description in case other better candidated for accessible name are present). And

It's also worth considering testing tools and testers.  If the calculation says it's ok and browser's use it then testers and tools are then forced to accept it unless they write specific cases to say something like flag the element when it has a placeholder that is the only method of calculating the accessible name  and then fight the up hill battle with authors who say I won't fix it because the browser is showing it as the name and the AT is saying it -- so it conforms -- and then we will be full circle having to accept it as the accesible name.  Telling someone they can't do it even though it's in the calculation sounds like an advisory -- and slapping advisory on something is likely to mean it won't happen.

Jonathan

-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk> 
Sent: Tuesday, August 7, 2018 3:48 PM
To: w3c-wai-gl@w3.org
Subject: Re: Bug: Firefox Accessibility Inspector reports placeholder attribute as eligible for accessible name



On 07/08/2018 20:38, John Foliot wrote:
...
> In either case, I will suggest that Firefox is getting it 'wrong' 
> /according to the spec(s)/, but given the prevalence of forms today 
> that are using @placeholder text exclusively to label form inputs, I 
> can understand why *_screen readers_* would ignore the spec in favor 
> of their users, prescribing to the "Priority of Constituents" 
> philosophy of Users over Authors, Authors over Implementors, and 
> Implementors over Code Purity.

Two points here: in general, screen readers will announce what the browser exposes via the accessibility API. So I'd wait before blaming screen readers. Secondly, Chrome exposes placeholder just the same way (can be verified using aViewer or the Accessibility panel in Chrome DevTools - an input with just placeholder and nothing else gets an accessible name using the placeholder).

> Given the other accessibility concerns around @placeholder text 
> however (noted in the W3C Warning but absent in the WHAT WG text), I 
> would be quite opposed to having the Accessible Name Calculation 
> algorithm changed, and would continue to +1 the bug as submitted to Mozilla.

I, on the other hand, would say the name calculation should take into account placeholder (as a last resort, which it currently is, and as an additional accessible description in case other better candidated for accessible name are present). And browsers should expose it this way. 
Yes, authors are discouraged/outright told not to rely on placeholder as the only labelling mechanism. But saying that the algorithm (and therefore browsers) should ignore placeholder for its accessible name calculation simply means that AT users will then encounter unnamed inputs, rather than having the browser at least expose the placeholder as a last resort.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 7 August 2018 20:29:28 UTC