Re: Further example of application/remote applications

On Sep 26, 2011, at 4:50 PM, David Singer <singer@apple.com> wrote:

> 
> On Sep 26, 2011, at 13:32 , Charles Pritchard wrote:
> 
>> I urge vendors to re-consider their commitment to Canvas accessibility 
> 
> Really?  A lot of us are committed to accessibility in all that we do.  Do you really want that changed?

Yes, I want 'a lot of us' changed to -all- of us.

And I want the mindset applied to be common-sense and testable, just as security an privacy considerations are.
> 


Like security, accessibility breaks down when a low-level interface is deficient. And like security, everybody on the team should understand and apply best practices; they should not be left or pushed off onto a minority of experts. As a practice, pushing off security an accessibility to experts is a poor use of resources and increases the likelihood of long-standing bugs.

Yes, vendors, reconsider how you are handling accessibility. That accessibility team you have is only half of the equation. I'm sure you've learned this lesson with security procedures.


I've repeatedly demonstrated the deficiency in the canvas API, and the Apis that are used by all other application types, and the consequences ( see: Mobile Safari VoiceOver ).

My efforts have been rebutted by two arguments, mainly: use case and innovation.

This post was a response to the use case arguments. Many vendors consulted with their developers and have simply remarked that the "use case" has not been established. That's not an easy mindset to change, but I'm trying to do so by providing evidence.

The other argument is one for innovation. I'm happy to encourage innovation, but I'm not content to sit idle while existing infrastructure and semantics, the tools and methods that -everybody- currently uses, are neglected. The accessibility API technique of binding a region on the screen to an accessible object has been around for a long time. We only have a portion of it, via drawFocusRing. I consider existing accessibilty Apis as requirements, regardless of what future invention may come.

-Charles



-Charles

Received on Tuesday, 27 September 2011 00:13:41 UTC