Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

On Jan 22, 2010, at 3:09 PM, Ian Hickson wrote:

> On Thu, 21 Jan 2010, Richard Schwerdtfeger wrote [reordered]:
>>>> 
>>>> The intent is to include the vocabulary in CSS to form a media query 
>>>> in harmony with HTML 5 to choose the best content for the user.
>>> 
>>> Let the user choose what is best for them. You can't know if I prefer 
>>> an E-book reader or a high-contrast option. Which I prefer can change 
>>> from minute to minute.
>> 
>> nobody is saying you cannot. Selection should be a browser feature but 
>> not a content feature unless the author chooses to do that.
> 
> Can browser vendors confirm that they are willing to prominently expose 
> this new selection UI?

At Apple, our accessibility model for native apps is that users of assistive technologies always get the real app UI, but semantic information allows them to receive the information and/or operate the controls in other ways. So you don't ever write a full contrast UI. The user just goes to the Universal Access panel in System Preferences, and chooses one of several high contrast options (including white-on-black display, grayscale, and a contrast control). The the OS applies it to all running applications. We believe that application authors are likely to implement multiple wholly separate user interfaces for different accessibility needs, so instead we give them the tools to build a single interface adaptable to many needs. Furthermore, we think it is good in principle if users with accessibility needs are fundamentally using the same interface. If a blind user and a sighted user are using fundamentally the same UI, just operated in different ways, then it is much easier for the two of them to collaborate, or give each other technical support or just helpful tips. We believe in this so strongly that we actually have visual onscreen elements for certain features that are intended for the blind. For example, when braille output is enabled, it displays to the screen as well as to a braille output device.

I can't imagine we would want a different or more complex model for Web applications than we do for native applications. I can imagine that in some rare cases, modality-specific UI may be truly necessary. But encouraging that as a common or default model would not be in line with our approach to accessibility. Our built-in accessibility features in Mac OS X and iPhone have been praised for their polish and ease of use, and we would not want to take a step back from that on the WEb.

Regards,
Maciej

Received on Saturday, 23 January 2010 00:19:27 UTC