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 09:33:06 UTC