[Accessforall] The Application Block
cclark at ocadu.ca
Wed Feb 8 23:13:19 UTC 2012
Thanks for your note. Comments inline...
On 2012-02-07, at 3:46 PM, Andy Heath wrote:
> The notion we used in AfA 3 (very different to ISO 24751) is that an application should conform to the appropriate Accessibility API on the platform it runs on (such as Java-Accessibility, Windows, etc. note that these are now ISO standards in SC35). and that the preferences would be therefore be those for the platform and handled by direct communication between the app and the platform. That doesn't quite solve the problem though because there may be preferences which are just specific to the App which go *beyond* what is in the platform accessibility api.
Yes, that's exactly right. I really like the addition of the apiInteroperable property in AccessForAll 3.0. It's a great way to describe a resource's conformance to a standard, but as you say, it's insufficient to capture the specific settings and characteristics that are unique to an application or assistive technology. Try as we might, there will always be preferences and metadata that we can't fully model in the specification, but that implementers will need to carry alongside those that have been standardized.
> 1. We only did a minimal (i.e. Core) model yet - we wanted that to get aired and used before it was extended to all the stuff in 24751
I'm totally sympathetic to the amount of time and effort it takes to put together a ground-up rewrite of a specification like AccessForAll. Wearing my Cloud4all architecture and development hat for a moment, though, AccessForAll 3.0 can only be of theoretical interest to us until it supports more than just the content metadata branch. We're in the midst of building real software to personalize desktop, mobile, and cloud-based assistive technologies and operating system access features. At the moment, AccessForAll 3.0 doesn't include the resources we need, ISO 24751does. I'm really looking forward to seeing how the control and display branches look in AccessForAll 3.0 once the committee has had a chance to bring them back into the spec.
> 2. In 24751 (i.e. the current ISO model) the model was a "closed" one so application-specific preferences would soon be out of date as applications advanced. In the model we (i.e. Afa on the Fluid Wiki) are doing now that won't be a problem because when an app gets revised or another comes along one just adds new prefs for it.
Right. At first glance, the ISO 24751 model for application-specific preferences seems to include everything we need to be able to support both version-specific and general application-specific preferences. Here's a JSON representation of what's in the spec:
We'll be in a better position to give more concrete advice when we've had a chance to implement the first iteration of the GPII match maker component over the next few months, but so far what's in 24751 still seems reasonable and sufficient.
> I haven't published it to AfA-Fluid but I wrote a long critique of 24751. I don't think its worth posting as most are well aware of the 24751 limitations and we have now moved well away from its way of structuring things.
I'd be happy if you'd be willing to send me your critique of 24751. I've spent the past days puzzling through the AccessForAll 3.0 draft specifications and having long conversations with Anastasia to try to get a firm grasp on the rationale and motivations for the rewrite. I can see hints of it, but it's not yet well described in the draft.
Fill me in; this stuff is really fascinating.
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
More information about the Accessforall