[Accessforall] The Application Block

Gregg Vanderheiden gv at trace.wisc.edu
Thu Feb 9 05:43:49 UTC 2012


GV: comments below 
On Feb 8, 2012, at 5:13 PM, Clark, Colin wrote:

> Hi Andy,
> 
> 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.

GV:  and arent we going to a "format and processes" approach for next version of 24751 and putting the values in a registry?   that should allow 24751 to move forward more quickly - and let the registry develop over time..?
> 
>> 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:
> 
> {
>    application: {
>        name: "JAWS"
>        version: "13"
>        parameter: {
>            fancySettingThatOnlyJAWSSupports: true
>       }
>    }
> }
> 
> 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.

GV:  yes - even if OBE   - I think it would be good to post on the WIKI as a "ref doc". 

> 
> Colin
> 
> ---
> Colin Clark
> Lead Software Architect,
> Inclusive Design Research Centre, OCAD University
> http://inclusivedesign.ca
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120208/51b62ac9/attachment.html>


More information about the Accessforall mailing list