RE: Extensible ARIA?

Matthew King wrote:

“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.”

 

Agreed. This is probably the biggest obstacle for AT users on the web. The belief that a widget is inaccessible or broken, not because it’s either of those things, but because the interaction is alien and unfathomable.

 

“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.”

 

Good idea. I suggest that wherever this is specified though, it’s made abundantly clear that the AT should enable the user to turn off the hints. It wouldn’t be a good UX if you had to listen/consume the hint every time.

 

Thinking on this a bit further, I wonder whether there’s a case to think about a short and long version of the hint? So in an ideal world an AT user could choose to hear no hint, a short hint, or the full explanation?

 

Léonie.

 

-- 

Léonie Watson Senior Accessibility Engineer, TPG.

@LeonieWatson @PacielloGroup

 

From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: 04 April 2014 22:57
To: Cynthia Shelly
Cc: lwatson@paciellogroup.com; 'W3C WAI Protocols & Formats'
Subject: 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> 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> 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> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=53996 
  
From: Léonie Watson [ <mailto:lwatson@paciellogroup.com> 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/> http://adactio.com/journal/6719/ 
  
  
  
-- 
Senior Accessibility Engineer, TPG 
@LeonieWatson @PacielloGroup