Re: Regarding the accessible name calculation for aria-label within links?

I really am glad that we've had the chance to talk about these things, 
because it highlights what I think is a fundamental issue regarding the 
successful implementation of ARIA for AT users, and whether ARIA can be used 
as a scalable accessibility solution for end users.

I do understand your point about the name calculation not being relevant in 
all cases, and I agree. I don't think it is possible to use one algorithm 
that covers all element types equally, covering static containers with 
embedded active elements, active elements of one type such as links and 
buttons versus active elements like form fields with embedded content, 
frames, and so on.

In one confusing statement in the naming calculation for the spec, it states 
"Authors can use the current section as a guide for creating names and 
descriptions in their markup.", which is why I get developers creating ARIA 
implementations that they just assume will work, even though in practice for 
ATs, they don't.

I wish there was a general recommended algorithm specifically designed for 
each AT type, that would at least break out individual element combinations 
and desired calculations, so that there would at least be some sort of 
process for doing this consistently within ATs.

E.G

Algorithm for Screen Readers
Links and Buttons: Native A or BUTTON or via role=link or role=button: 
Follow naming calculation A.
Form Fields: Select or role=listbox, Edit Field or role=textbox: Follow 
naming calculation B.
Static Containers: Non-Active Static Elements (DIVs, SPANs, etc.): Follow 
naming calculation C.
Etc.

Algorithm for Voice Navigation Software
...

Algorithm for Screen Magnifiers
...

I know this is wishful thinking, and it has nothing to do with the W3C.

To be honest though, I don't think this problem will ever be solved without 
such a general recommendation for ATs, because interpretations will always 
very widely and some will never implement anything, because it's too 
difficult and expensive for some AT venders to figure it out, especially for 
the last two types.

----- Original Message ----- 
From: "James Teh" <jamie@nvaccess.org>
To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>; "James Craig" 
<jcraig@apple.com>
Cc: "Joseph Scheuhammer" <clown@alum.mit.edu>; <mick@nvaccess.org>; "Sailesh 
Panchang" <sailesh.panchang@deque.com>; "Schnabel, Stefan" 
<stefan.schnabel@sap.com>; "WAI XTech" <wai-xtech@w3.org>
Sent: Friday, February 14, 2014 4:24 PM
Subject: Re: Regarding the accessible name calculation for aria-label within 
links?


> On 15/02/2014 4:50 AM, Bryan Garaventa wrote:
>> If ATs choose not to follow the same calculations, it doesn't matter
>> what accessible names are provided in the accessibility APIs, because
>> they won't be reliably conveyed to end users anyway.
> The point is that if we always followed the name calculation and only used 
> that, we'd never render the content of labelled divs, spans, tables, 
> lists, etc. I don't know how I can clarify this point any further. An AT 
> can't just rely on the name calculation; it has to use other content and 
> it has decide which content to use. That is where things get tricky: how 
> to make that decision. That is the bit that isn't covered by the spec.
>
> To consider it another way, when we use the name, we're ignoring other 
> information exposed by accessibility APIs such as children/content. You're 
> only considering one aspect of what is exposed.
>
>> The only solution I can see at present, is to file relevant bugs where
>> inconsistencies are noticed, and start a dialog where cooperative
>> agreement may then be possible to figure out.
> For sure. I'm happy to engage in such dialogue and implement the best 
> possible solution. That said, almost every time something like this and 
> several other contentious changes are requested, the phrase "in accordance 
> with the spec" (or something similar) gets used. If we blindly followed 
> the spec with regard to label as suggested in this case, we'd break 
> several cases I've mentioned. The alternative is that we can make 
> decisions about what is best for authors and users in the majority of 
> cases, but then we're often accused of not following the spec or imposing 
> our interpretation of what is correct. We can't win. The web accessibility 
> community can't have it both ways. People can't use so-called spec 
> compliance to support their arguments and then claim we should just do 
> what makes sense when that doesn't suit them.
>
> For what it's worth, I'm working on a solution which will hopefully cover 
> the majority of cases, including yours. However, the label can't override 
> on divs and spans without a role (because that would break labelled 
> landmarks, regions, etc.) and I am certain that several people will be 
> unhappy about this.
>
> Jamie
>
> -- 
> James Teh
> Director, NV Access Limited
> Ph + 61 7 5667 8372
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @nvaccess

Received on Saturday, 15 February 2014 23:38:15 UTC