W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2008

Re: Processing requirements for secondary and seealso missing

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 27 Mar 2008 11:24:33 +0200
Cc: public-pfwg-comments@w3.org
Message-Id: <CCE50BBD-0DD8-4815-AC75-9E3C197959E5@iki.fi>
To: Lisa Seeman <lisa@ubaccess.com>

On Mar 27, 2008, at 09:25, Lisa Seeman wrote:
>>> I think the processing requirements in this case are simple - enable
>>> adoption to your user base needs.
>> That's totally vague. That's not a processing requirement that  
>> leads to
>> interoperable implementations.
> Henri,
> In cases were accessibility for the blind is a key issue then  
> processing
> instructions to map to the accessibility API is given.
> However, in the case of adaptation for learning and cognitive  
> disabilities I
> strongly believe that no person - and certainly not this working  
> group can
> identify all the scenarios and possible adaptations combinations.
> Therefore the idea is to enable adaptability by exposing what things  
> are.

Considering that screen readers are a major target, the fact that  
there may be other kind of AT is no reason to leave expected behavior  
when ARIA is used in a screen reader setting undefined.

I'm not saying that ARIA should prescribe screen reader UI. However,  
ARIA could, without prescribing screen reader UI and without referring  
to particular APIs, define expected UI mapping by the way of  
equivalence to various system widgets and their states for the AT  
modality in use. For example, I don't find a functional "must" stating  
that a role=checkbox must be exposed to an AT user in the same way as  
a platform-native checkbox. The section that comes closest to  
discussing practical accessibility API exposure is marked informative.  
The normative section just says that software must do the appropriate  
thing without defining what's appropriate e.g. in terms of equivalence  
to system widgets.

Even if having a 'must' for the above-mentioned equivalent exposure  
seems too obvious or daft, the spec fails to give processing  
requirements concerning, for example:
  * What to do with DOM subtrees rooted at widget roles that are  
supposed to be leaf nodes in the accessible tree?
  * What events exactly must fire when a user uses AT to change widget  
state? Script authors need to know what events exactly they need to  
respond to.
  * The text about aria-level and aria-posinset basically tells script  
authors that UAs may do random stuff and the script authors should  
test with various implementations. Leaving stuff like that  
implementation-defined is not good for getting interop. Specs are  
supposed to lead to predictable behavior so that author don't need to  
work around that kind of randomness.
  * The spec doesn't say what the UA is to do when valuemax/min/now is  
missing or now is out of range or min and max have been swapped.
  * What must UAs do when posinset < 1 or > setsize?
  * What must UAs do when setsize < 1? (Why aren't empty sets with  
setsize = 0 allowed?)
  * How must a UA compute the set size and the item position when all  
items are present in set and posinset and setsize are omitted?
  * How must aria-level interact with host language-native section and  
heading level algorithms?

There are miles to go in terms of processing requirements before even  
touching adaptations for learning and cognitive disabilities.

> We do not want to write a specification that dictates all possible
> processing for different layouts - I do not think you want a  
> specification
> with 100's of options iether.

In that case, it isn't reasonable to expect authors to address  
accessibility for the learning disabled or the cognitively disabled  
specifically in a loosely-coupled distributed system like the Web. If  
authors have no way to assess the effect of their actions, how can  
they code for particular effects?

That leaves the adaptations working with whatever has been put in  
place for the purpose of addressing more tractable scenarios in a  
loosely coupled system (that is, reusing stuff that was intended for  
screen readers). Or writing for a particular adaptation product, in  
which case the authoring scenario is not in the realm of an open multi- 
vendor loosely coupled system that is the Web anymore.

Note: Just telling people to put stuff out there without evidence of  
concrete benefit from the effort erodes trust in expert advice:

> Were no processing instruction is given a normal browser can ignore  
> the role but an AT can use it.

I think there are two levels of assessing what an implementation is  
doing with ARIA markup:
  1) Full stack: e.g. Firevox alone or a browser and a screenreader  
observed together with the communication between them being an  
implementation detail.
  2) Web engine to accessibility API: How a Web engine implementation  
(a browser) exposes things to an accessibility API.

I think it is reasonable to define behavior by equivalence to user  
perception of system-native widgets in the case of full stack  
conformance. In the case of accessibility API exposure, particular  
APIs would have to be mentioned concretely.

Henri Sivonen
Received on Thursday, 27 March 2008 09:25:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:57 UTC