Re: Questions arising from ARIA/HTML5 integration

( Apologies as I don't wish to hijack this thread - but I do wish to
make some points in relation to Steves response to Ian.)

Steven Faulkner wrote:
>> Would that result in the optimum interface in an AT?
> 
> the optimum interface would result from the correct mapping to the
> accessibility APIs for the controls that make up the interface and may
> include instructional content being provided using the appropriate
> properties.

+1, that would be a great start but I don't know if it would just result
in the 'optimum interface'. Some recent user testing I have done - of an
ARIA enabled application - with a visually impaired screen reader user -
has really hammered home to me how we need to be /very/ aware of
additional complexity in RIAs and its potential impact on users of AT.
Of course in some cases it may be necessary, and indeed unavoidable.

So while I completely agree with Steves point, I say that successfully
mapping to the accessibility API is actually only the start - as how the
resulting mappings are implemented and interpreted will have a profound
impact (for better or worse) on the usability of the applications to
which they are applied. I realize also that this list is maybe not a
suitable forum for the minutiae of this kind of discussion on AT and
usability but it would be remiss of me if I did not make the point.


> If the controls are implemented in the browser, but not hooked up to the
> accessibility APIs or instructional content is not provided or the
> accessibility APIs available do not provide features that ARIA does,  and
> the browser supports ARIA, then the use of ARIA  could provide the optiimum
> interface to AT.

and in terms of how this would be implemented in AT (now) would probably
be dependent on current AT support for parts of the ARIA spec, such as
Landmarks, Live Regions etc - or if elements with ARIA roles could be
just  easily tabbed to by the user and automatically announced (rather
like how a link, or other form control currently is) then this would
take advantage of the descriptive capability of ARIA without the user
having to learn a new keyboard command and so on.

When the issues that are arising as a result of ARIA integration in HTML
5 are resolved, I think we will yet see some deletion or culling where
there are duplication issues etc, then we will be able to more clearly
see where user agent issues like AT implementation could be headed.

>>> none, as far as I can tell , could not find accessibility API mappings
> for
>>> any of these
>> Is that a problem?
[...]
> the mapping to the accessibility APIs would depend on the implementation, if
> there is no
> appropriate mapping and this results in the elements not being
> understandable or usable by AT users then yes. for example , the canvas
> element currently has no mapping, and thus is not there for AT users.

As we don't yet know how <canvas> could be successfully used by VIP
users of screen readers. FWIW it should be based to some degree on what
users /already/ do and build on the behaviours  and models of user
interaction that they have come to expect - basically don't  force a new
model of interaction that is overly complex. If users can successfully
tab to elements, or nodes  and use their cursor keys - with some known
modifier key - for example then fine. Actually <canvas> will probably,
if anything, emulate Flash.

Cheers

Josh

Received on Friday, 4 September 2009 12:10:54 UTC