ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect)

jcraig@apple.com wrote:
>
> Also, ARIA is not supposed to affect mainstream UI, and your suggestion breaks that pattern.

Hi James, All,

I have heard this assertion stated that way before, and I would like to know the history of that thinking, as when I read through all of the ARIA documentation at the W3C, that idea does not seem to be explicitly expressed, and in fact I can find passages that allude to the contrary.

 "WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies."
(source: http://www.w3.org/WAI/intro/aria.php) 

Focusing on "advanced user interface controls", I absolutely agree that for blind users that statement directly suggests a non-visual solution that screen-readers will both announce and interact with. The addition of ARIA, and the overall general uptake of ARIA to-date has been a huge boon for non-sighted users, but, is that the only target audience for ARIA? The intro states "people with disabilities", not "people who are blind", and so by my reasoning and extension, ARIA *should* also benefit other user-groups within the larger definition of "people with disabilities".


 "WAI-ARIA addresses these accessibility challenges by defining how information about this functionality can be provided to assistive technology. With WAI-ARIA, an advanced Web application can be made accessible and usable to people with disabilities."
(source: http://www.w3.org/WAI/intro/aria.php)

"... defining how information about this functionality can be provided to assistive technology..." - there are many AT tools that affect the mainstream UI, to the benefit of end users. Screen magnifiers routinely change the UI (sometimes by over-riding color pallets/choices); tools such as Dragon, when used to navigate a webpage will "add" visual focus points on demand, and more mainstream accommodation strategies, found both on the web and in other meat-space examples, also make adjustments to the "mainstream UI" (consider Closed-Captions as a user-setting change to the UI).


The stated technical goals for WAI-ARIA are:

 "...WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. WAI-ARIA describes new navigation techniques to mark regions and common Web structures as menus, primary content, secondary content, banner information, and other types of Web structures. For example, with WAI-ARIA, developers can identify regions of pages and enable keyboard users to easily move among regions, rather than having to press Tab many times.

 WAI-ARIA also includes technologies to map controls, Ajax live regions, and events to accessibility application programming interfaces (APIs), including custom controls used for rich Internet applications. WAI-ARIA techniques apply to widgets such as buttons, drop-down lists, calendar functions, tree controls (for example, expandable menus), and others."
(source: http://www.w3.org/WAI/intro/aria.php) 

Now, maybe it's just me, but nowhere within that statement do I see it expressly stated that ARIA cannot effect change to the "mainstream UI" - don't get me wrong, by default I support that idea as a default setting, but there is a middle ground that seems to be being ignored here: end-user control.

Returning to the example of Closed-Captions: clearly, when Closed Captions are "turned on", they make a change to the user interface - there is now a text box on top of the video region that was not originally there. By default, most Closed-Captions however are *not* shown: the default is that they are "turned off".

Then there is Dragon: Saying CLICK LINK will place numbered markers at all text hyperlinks on the visible webpage so that the end user can select a specific link "by number" - clearly this too is a "mainstream UI" change, this time one that is being applied by the Assistive Technology in question (is Dragon AT?) when it over-lays the numbers.


However, the most contradictory information I could find at the W3C that questions your assertion was this:

 "The WAI-ARIA specification neither requires or forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities. "
(source: http://www.w3.org/TR/wai-aria/complete#ua-support_header) 

Right there, in black and white, it says "...neither requires or forbids", which therefore leaves open the door that changes to the default UI *can* be impacted by the use of ARIA, and it further opens the door that suggests that this may in fact be a Good Thing (TM). That statement also indicates that "Mainstream user-agents" could indeed make UI changes to "...facilitate navigation for all users", and frankly I think that making ARIA more "mainstream" for all users would be a huge win: at times it still feels that ARIA is the accessibility ghetto, the exclusive domain of screen reader software - a position that I personally find troubling.

For these reasons, I bristle just a bit when we are absolutist in the notion that ARIA "...MUST NOT (RFC 2119) make changes to the Mainstream UI" - I am significantly closer to "ARIA SHOULD NOT (RFC 2119) change the default UI without user-intervention", but I also reserve the concept that for some users, changing the UI is in fact a significant part of their accommodation strategy, and if/when ARIA can positively assist in that, we should embrace, not shun, that ideal.

Like many of us, I've been around the block a time or two, and I absolutely understand how we need to work *with* the design community, and not against them by imposing strange rules and requirements that they struggle to understand, never mind artfully integrate, but again, the end user MUST (RFC 2119) have a direct impact on how they can configure *their rig* to provide accommodations to their needs. If a combination of ARIA and AT user-interface changes accomplishes that feat, we are winning. 

Conclusion:
Stating categorically that ARIA must never have an impact on the UI seems to be counter-productive, and I would suggest that if that requirement is explicitly stated somewhere in the ARIA documentation today, that we should re-open that discussion, with a goal of better fine-tuning (wordsmithing) what is really meant (if, in fact, there is agreement on *that* point).

Thoughts?

JF
​-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

Received on Thursday, 17 September 2015 18:23:27 UTC