I think
http://www.marco.org/2014/07/10/app-review-should-test-acces...
would be a good way to deal with this. As a blind iPhone user I don't think all apps should have to be made accessible. For example I will never play Angry Birds or use image editing apps. While inaccessible updates are an issue this resolution is overly vague. It would be better if there was a section 508 type standard for mobile apps that productivity apps could use as a guide to accessibility and that governments and companies could hold app developers accountable to.
What advice would you give to someone developing a windowing system that allows the arbitrary placement of "layers" in a 3D space for sighted users, where each layer represents content such as an HTML document? I know where I can find basic information for incorporating existing affordances like those in WAI-ARIA, but I haven't a clue where one would start learning the basic underlying principles for designing any fundamentally graphical system for eventual use by the blind.
FWIW, I'm one of the software engineers at famo.us and I'm genuinely curious about knowing how to start designing accessibility features normally found in operating systems, rich application frameworks and windowing systems (qt, kde, gnome, cocoa, wpf, UIKit, AppKit, etc.) from first principles.
At the end of the day, at famo.us we're fundamentally exploring and implementing concepts in client-side JavaScript that have historically been the domain of the user agent makers and been implemented directly in browsers and accessibility tools like screen readers. With that in mind, do you know of people/projects/efforts to implement accessibility features directly in JavaScript? If not, what kind of accessibility features would you like to see that could be implemented in client-side JavaScript?
At the end of the day, HTML Documents have always been linear in nature, but applications are fundamentally non-linear, so a lot of the concepts I'm familiar with don't exactly map to what we're doing with scene graphs. Furthermore, the trend for interface designers to explore z-depth as an affordance makes things simpler for sighted users, but I would imagine complicates things for visually impaired users.
Lastly, besides the recently founded "a11ybay", are there any other notable developer communities/meetups you know of in or around San Francisco where one can meet engineers specializing in accessibility.
Since my job is mostly Mainframe programming I don't have much experience with accessibility from a developers point of view. You might want to try and get in contact with people at
http://www.paciellogroup.com/
though, I've read there blog and it looks like they know what there talking about.
The accessibility community is very small and highly networked. I can introduce you to individual developers if you are interested. I guess HN doesn't allow Private Messages, but you can find me on linkedin linkedin.com/in/chrmaury
May be worth pointing out for iOS devs doing automated testing - KIF (and maybe Frank, I'm less familiar with Frank) hijacks the accessibility labels on controls in order to facilitate input injection.
This breaks a lot of the implicit/default blind accessibility behavior of the OS.
If you're using KIF, please make sure, even if you're not putting extra effort into accessibility, that at least you're not breaking the defaults with your testing framework.
At the other end of the spectrum, there's Subliminal[1], which relies on Apple's UIAutomation underneath, which in turn relies on the application's accessibility information as-is, rather than hijacking it. Building up tests using either UIAutomation or something that sits on top of it like Subliminal will actually help you improve your app's accessibility at the same time.
This. One of the common stories in accessibility circles is "curb cuts", the ramps from streets to sidewalks that allow disabled people easier access than a stepped curb. They have utility for non-disabled persons towing roller luggage, pushing strollers, pulling hand-carts, etc. While they were put in place due to accessibility concerns, they benefit everyone.
Accessibility facilities that enable UI automation are the "curb cuts" of software.
