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

>> It's not appropriate for the W3C to tell a screen reader or other assistive technology how to behave on a platform API, because neither of these are W3C technologies.

I understand also that from the HTML and CSS specs, the shape of a button element is not defined ... And this is good.

Hmmm.. many of the questions asked here in this thread seems to imply that ARIA specs can be interpreted as such behaviors. 
I do know that this is wrong, that's not the point. I just observe that people search for *anything* more precise here.
Time to clarify this. The question is if all people are OK with this degree of freedom.

>> but not all roles are applicable to all systems or interfaces, and some accessibility APIs don't even have a concept of role

I won't force anybody to put his boat on wheels and name them if the thing is never intended to leave the water. But if it has a motor, it should be named as such. Makes sense?

Stefan

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Freitag, 14. Februar 2014 02:28
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 13, 2014, at 6:26 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:

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

I wasn't trying to be flippant or imply that the differences between CSS renderings was trivial. Just that the major differences were pixel-based display rendering differences, and every system affected had a screen that rendered pixels. This is admittedly still a generalization, but my point was that the differences between various types of assistive technologies are even more substantial than changing pixel renderings. You mentioned your expectation that "role" would always be spoken by default, but not all roles are applicable to all systems or interfaces, and some accessibility APIs don't even have a concept of role. Likewise, keyboard and other interaction behaviors and AT-specific navigation modes are radically different than the mainstream mouse and tab key interaction behaviors that have normalized across most GUI systems in the last 30 years.

My point was just that this is a much more fundamental difference than pixel display renderings, and since these screen reader behavioral differences are not "bugs" it would be inappropriate for the W3C to release a spec telling them to change their behavior. 

Also, that it's within the scope of the W3C to specify how HTML and CSS are rendered visually, and even how HTML and CSS are mapped to platform APIs, because HTML and CSS are W3C technologies. It's not appropriate for the W3C to tell a screen reader or other assistive technology how to behave on a platform API, because neither of these are W3C technologies.

James

Received on Friday, 14 February 2014 15:10:00 UTC