[Accessforall] The Application Block

Liddy Nevile liddy at sunriseresearch.org
Wed Feb 8 23:40:08 UTC 2012

I agree

- Andy, please share your critique of 24751 because we are not yet  
clear about what we should do in the future.

I think the point about details and devices etc is really important.  
In the metadata world, we have learned that it is really important to  
be able to have global and local metadata mixed together. That means  
that if I have something that is important, implemented, and of use to  
my community, I want to be able to add that to the metadata without  
having to ask anyone or change any functionality. On the other hand,  
it might be something that I don't really want to share, or that is  
unlikely to be of interest to anyone else.

As Eric Miller pointed out yesterday, one of the great things about  
the Web and using the web as a database is that then things can be  
added without recourse to some agency or authority - this is critical  
to our clientele, I think.


On 09/02/2012, at 10:13 AM, 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.
>> 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.
> 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

More information about the Accessforall mailing list