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

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-html-request@w3.org wrote on 01/22/2010 06:18:41 PM:

> Maciej Stachowiak <mjs@apple.com>
> Sent by: public-html-request@w3.org
>
> 01/22/2010 06:18 PM
>
> To
>
> Ian Hickson <ian@hixie.ch>
>
> cc
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, James Craig
> <jcraig@apple.com>, public-canvas-api@w3.org, HTML WG <public-
> html@w3.org>, David Singer <singer@apple.com>
>
> Subject
>
> 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.
>
Regading response to system colors, I like this approach as well, however
the CSS working group was unable to provide standardized system information
on the OS to a web application to tell the author the author requirements.

Regarding two users operating off the same content. I would agree to a
point. However, I feel you may not be considering more challenging use
cases and users. For example, a cognitively impaired user may not be able
to process the complexit of a particular application. Rather, they may need
one that is much more simplified that has to gradually introduce content at
the users request. Also, for may a subway map is often provided on some
sites. It is not something that is operated. However, a blind user will
need to take the information in the subway map, enter in data and generate
route to take on the page. At the same time a cognitively impaired user may
not be able to handle the complexities of a subway map as there is too much
information provided. It is for these reasons that the learning and
education space has developed Access For All to deliver content that best
fits all users based on their needs.

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

A much as a bigot I am about Apple products I think you need to take a
broader perspective than you are. So, please let me enlighten you further
by providing you with a slightly different scenario: Even web content
providers scale down content to fit devices to deliver the pertinent
information based on the display real estate. This makes the content easier
to use. Yet, in doing so two people cannot sit side by side (desktop and
IPhone user) and directly operate the same application side by side. These
principles are no different than providing reduced content to a cognitively
impaired user. Making all that possible meant knowing the capabilities of
the device the content is targeted at. The same should be the case for a
user's needs.

Going forward, we are going to find that making content more usable will
also require adaptation to the environment the user is operating in. This
means lighting conditions, background noise, etc. Content will need to be
context aware and adaptable.

I think the IPhone is a fantastic tool but even Apple can improve on what
it is doing. This is not a step backward for Apple.

>
> Regards,
> Maciej
>
>