Sorry. It still reads like a joke, but I know you are a professional. I am confused. Can you please provide a reference or two demonstrating that this is actually a real concern for anyone in the accessibility community?
Something as simple as the slide to unlock, which is more comfortable to slide when the iPhone is held in your right hand as opposed to your left hand; it is more comfortable to active the slide to unlock left to right as opposed to right to left. Another example is the edit button on the bookmarks page, which is more comfortable to hit with your thumb when held in your right hand. These issues only really appear when you operate you iPhone with a single hand.
In other words, you have absolutely no references -- no formal papers or not even a blog article -- that this is actually a real concern for anyone in the accessibility community. It is just a joke.
Regardless of what Steve Jobs wrote in that PR piece, accessibility had nothing to do with their decision. If it were they would have built a left-handed/right-handed toggle into an OS which is dynamic at its foundation.
And that joke is the "reason" for the blanket statement that Apple doesn't care about accessibility. Your house of cards just came tumbling down.
I can make it mostly accessible. You don't need a screen reader if the swf elements do voice overs for example.
If an individual business is built to be accessible to customers in wheelchairs, does that mean that every business in the community is wheelchair-accessible?
If individual businesses all spec and design their building's accessibility in an ad hoc manner, how well will accessibility work in the community as a whole?
Apple lists all of the accessibility widgets provided in the iPad in the user manual: chapter 21 in
the current manual for iOS 4.3.
Could some Flash app code and serve up all of those accessibility widgets in its app? Maybe. Assuming that Flash has access to the APIs -- which is by no means a certainty -- it would be a lot of code for an individual Flash app to contain. It would take a lot of work for the individual developers to ensure that all that code behaved flawlessly with his app. I don't want to even think about how different developers would ensure that their accessibility adapters would work the same way in their individual Flash apps.
Should that Flash app be able to access the accessibility options that an individual has specified?
No. Absolutely not. If an app could access that information, it could harvest that information and abuse it. How an individual has the accessibility widgets configured is personal and private information. To maintain privacy of this information, individual apps (including your hypothetical Flash app)
cannot have access to it. But if the app can't know which accessibility routines to use, how can the content be served up with accessibility?
These are two monster problems. As far as I can tell, both of them are problematic. Even if Flash developers and their clients were highly motivated to provide accessibility in a single app, it's extremely difficult to do. And let's not even think about the aggregate user experience of a bunch of Flash apps each implementing accessibility in their own ad hoc fashion.
I liked the way you said it:
mostly accessible. Accessible in sort of a half-assed way. A highly-motivated Flash developer working for a highly-motivated client could do no better than make a half-assed implementation of accessibility in a Flash app.
But the simple truth is that none of my clients ever said make this site accessible for the blind.
That's a brilliant observation. You add a dimension to the "lowest common denominator" argument that Jobs discussed in his sixth point in the
Thoughts on Flash memo. Not only is the Flash platform the lowest common denominator of what's available on all platforms, but clients are only motivated to provide the lowest common denominator in their app functionality. Resources will always be limited. As a practical matter, accessibility adaptations would never make the feature list.
While I doubt that Apple will ever make a 2.0 version of the "Thoughts on Flash" memo, your point would definitely be worthy of inclusion in an updated version of that essay. Cool.
Our attention now turns to the pink elephant who has been patiently dancing in the corner:
Do you see any way to make the web accessible for all without flushing Flash?
Ok, let's put an end to this discussion once and for all.
In the middle of this discussion, I realized that Flash enthusiasts didn't really understand the fundamental architectural limitation of Flash -- and why Apple made the strategic decision to have iOS devices be Flash-free. In short, they never
read the memo or understand the most important reason highlighted there.
From
@darngooddesign's contribution above, we just identified a new reason why accessibility and Flash are mutually incompatible: the economics of the individual client. I think that's a valuable idea for everyone in this thread to understand. As far as I can tell, individual clients will never put a priority on the accessibility of their website. Since resources will always be scarce, how could we ever ensure accessibility across the entire web?
The answer seems pretty clear: have a standardized method for data to be sent to the client (HTML), and send the data in a transparent fashion. If the user wants any accessibility widgets to be applied to the clients data, have him turn on those options and have his web browser apply them to the data. Clients just have to provide transparent data (free of Flash or other opaque data presentations) to have websites be accessible. If all websites are Flash-free, then all websites will be accessible.
Apple has committed tremendous resources to accessibility on their laptop, desktop, and iOS machines. As part of the initiative, they realized an interesting thing: the value of that work will be enhanced as the entire web shifts to being Flash-free. Brilliant.
