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

I'd like to comment on some of your answers.

>> If the W3C starts making normative statements based on incorrect assumptions like these, it's just not going to work.

It is not about "making  normative statements based on incorrect assumptions". It is just very debatable from an architectural point of view if people's behaviors or what they are used to use should form up a "standard" or legitimate the non-presence of such. What I meant is the specified basic *ability* for AT to give all such info *on user request*, not as an engraved-in-stone default behavior. I know AT/UA-combinations where this is *not* possible since the required functions/API's are simply not supported. And I doubt that there were always end-user-centric reasons for that.

>> The UI differences between various screen readers are radically different than a few pixel differences 

You know that it was WAY more difference than "just a few pixels". Entire layouts broke down and design schools that required in-web pixel-perfectness were upset. It's the same story: The work of a few content authors affected everybody. This is also true for somebody who provides accessible markup and metadata and cannot rely on that all he provided will be caught up properly by any given AT/UA combination. Seeing that as a sporting race that will resolve with time "when AT gets better" is best, say, ingenious and won't help neither the content authors nor the users.

>> There are purposeful gaps in HTML and other specifications so that they don't accidentally specify something that would inhibit innovation

The art is to specify without inhibiting innovation. Otherwise you sell desultoriness as flexibility. You can't e.g. seriously defend that after 20 years of HTML we still have no data grid, tab strip and dynamic tree element concept being part of core HTML form element specs. The result was a mess of e.g. custom tree implementations with totally different level of accessibility support. It was just *unimportant* for the majority, as maybe having common speech definition assumptions for different AT/UA combinations. 

>> Even users on the same screen reader customize their interfaces significantly.

I always welcome and encourage end-user personalization as a part of software features. No contradiction here to what I said. The point is that the *basis* what should be exposed to personalization is not cross-platform defined. And if you say on platform x there is no support for role y, therefore to say configuring to speak a role makes no sense - well, same story as above. You either buy technology-agnostic specs or not.

>> The brilliance of WCAG2 is that it never decreed interface specifics such as a keyboard. 

Generic formulations like the cited WCAG2 do help generalizing requirements (concrete implementation proposals are done in best practices). In this sense I do see the requirement to include *on request in any order* the role, the text, the state, the hierarchy, but also the position and so on in the info. Also no contradiction.

Best Regards
Stefan


-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Donnerstag, 13. Februar 2014 10:33
To: Schnabel, Stefan
Cc: James Teh; mick@nvaccess.org; WAI XTech
Subject: Re: Regarding the accessible name calculation for aria-label within links?

On Feb 6, 2014, at 2:29 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:

> To give one example, everybody "expects" that a number of things are spoken for e.g. a hierarchical list item, the role, the text, the state, the hierarchy, but also the position ("2 of 5") within its siblings?

I don't agree with this claim. I know screen reader users that minimal verbosity settings and want nothing but the label spoken: no role, no status, no other contextual information. I know others that want everything spoken, but they customize the order for each type of control. This is the way they are used to interacting with their OS and the Web. I even know of operating systems where the closest equivalent to your example of hierarchical list items is presented so differently that hearing a position or level would seem entirely irrelevant. If the W3C starts making normative statements based on incorrect assumptions like these, it's just not going to work.

Certainly we want web browsers to expose these roles, labels, and other information to APIs so that AT can use it, but I'm unconvinced that you can or should write a formal specification decreeing the user interface of screen readers. 

> ...which brings us back to the initial question: Do we all want that the gaps/differences SHOULD BE smaller?

I understand your analogy to CSS here, but that specification normalized the difference between thing like pixel layout and rendering. That was fine and necessary because all systems rendered pixels in more or less the same way. The UI differences between various screen readers are radically different than a few pixel differences, and that's not a bug, it's by design. Even users on the same screen reader customize their interfaces significantly. There are purposeful gaps in HTML and other specifications so that they don't accidentally specify something that would inhibit innovation, or would not work for a particular user interface. 

Need I mention that almost all accessibility recommendations until 2009 required that interfaces be usable with a "keyboard" and "keyboard focus"? Many still do. There was not even acknowledgement that systems and devices may change until WCAG2. The brilliance of WCAG2 is that it never decreed interface specifics such as a keyboard. Instead it said, "all content must be operable." Sometimes that meant via a keyboard or keyboard interface, but the keyboard-specific language was a technique to achieve the requirement, not the requirement itself. 

James

Received on Thursday, 13 February 2014 14:27:18 UTC