RE: Extensible ARIA?

In this discussion, we are fast approaching the need for standardized ways 
of ensuring operational hints can be spoken for any widget in a non-visual 
interface. I don't know any other way the combination of control patterns 
associated with a previously unencountered "FooWidget" could be made 
perceivable and understandable.

So, to be perceivable and understandable, we might have to require 
developers to provide operational hint content whenever an operational 
widget has a custom role. If the control patterns themselves are 
standardized through something like Indie UI then declaring that 
"FooWidget" supports invoke, select, and droptarget could make it possible 
for the operational hint information to be generated dynamically.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Cynthia Shelly <cyns@microsoft.com>
To:     "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, "'W3C WAI 
Protocols & Formats'" <public-pfwg@w3.org>, 
Date:   04/04/2014 01:57 PM
Subject:        RE: Extensible ARIA?



One thing we’ve talked about for ARIA 2.0 is the idea of adding something 
similar to the Control Patterns in UIA.  Control patterns describe 
behaviors, like invoke, select, droptarget, etc.  They include properties, 
methods and events.  They can be combined to describe the behavior of UI 
controls that don’t fit neatly into a role.  These would then be given a 
name in the Localized Control Type field, as discussed in an earlier 
thread.
 
In UIA, a role is called a control type, and every control type has 
required control patterns.  For example, buttons must support invoke. Some 
control types also have optional control patterns. 
 
This model allows for a large number of combinations, and custom naming. 
It’s pretty powerful. 
 
There are also mechanisms for custom properties, events and patterns. That 
might be more than we want to bite off in ARIA 2.0.
 
You can read more about patterns here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee671194(v=vs.85).aspx
 
More about UIA in general here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee684076(v=vs.85).aspx 

 
UIA has also part of ISO/IEC TR 13066-2:2012 available at:
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=53996 

 
From: Léonie Watson [mailto:lwatson@paciellogroup.com] 
Sent: Wednesday, April 2, 2014 1:16 AM
To: 'W3C WAI Protocols & Formats'
Subject: Extensible ARIA?
 
Hello,
 
Web components offer exciting possibilities, and accessibility is going to 
need to keep pace with this potential. This came up at EdgeConf recently, 
where ARIA was widely thought to be the solution amongst developers.
 
I’m not sure that ARIA (as it stands) can keep pace with the near infinite 
range of components that developers could/will create? It seems improbable 
that the ARIA spec could ever encompass every/any element/role that a 
developer might conjure up.
 
Jeremy Keith made this point at EdgeConf, and also suggested the 
possibility of ARIA becoming extensible [1].
 
I thought it was worth raising here for discussion. Apologies if it’s 
already being discussed here or elsewhere.
 
Léonie.
[1] http://adactio.com/journal/6719/

 
 
 
-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup