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

TL;DR

If we accept that HTML is for semantics, and CSS is for display, and that ARIA abstracts "behavior" in scripted behavior - and that the browser can adapt the HTML without the use of Assistive Technology to meet the user needs, and CSS can be modified by the end user in their browser without the need for AT, *WHY IS IT* that when it comes to ARIA/behavior, the end user cannot make any UI changes (or even leverage the marked-up attributes) without first mandating inserting Assistive Technology into the mix? (Or, more simplistically, why are we reserving curb-cuts *ONLY* for people in wheel chairs?)

*****************
Sailesh Panchang wrote:
>         "The WAI-ARIA specification neither requires or forbids user agents from
> enhancing native presentation and interaction behaviors on the basis of WAI-
> ARIA markup.
> SP:I interpret "changing the UI" as visual changes to the UI.
> Surely ARIA MUST not make visual changes ... that is the prerogative of  the
> content authors or user agents / AT.

Actually Sailesh, I'd argue that it is the prerogative of the *end user*:  that accessible content can be "reformatted" to serve the needs of the individual. I reference a long-held catch-phrase "author proposes, user disposes" as the roots of my assertion.

> ARIA primarily helps by exposing role, state, name  to accessibility API available
> to user agents including adaptive technologies.
> 
> Now the above sentence you quote means, "Browsers may or may not
> introduce special presentation to make ARIA-landmark region visually
> discernible" like they do for headings, lists, fieldsets etc by default.

Essentially correct. I am saying that user-agents can (MUST?) have a default rendering that directly matches the creators vision for the GUI, but I am also suggesting that "AT" alone need not be the only user agent (or part of the UA stack) where modifications, including changes to the UI, can be made. For example, I can go into the browser and change the default setting for my text settings, so that when, for example, EMs are used in CSS (or percentages) that they are a percentage of my default font-face setting. The default in most (all?) browsers today is font-face@ 100% = 16pt., but if I want to change that to 24pt as a low-vision user I can, and __it changes the UI__. (Furthermore, I can explicitly over-ride the author's intentions)

My reading of James' statement is that this would not be... and I'm not sure if appreciated is the correct word, but that somehow this isn't an accessibility consideration: that ARIA is almost exclusively for the domain of assistive technology, that 'browsers' should be doing nothing with ARIA, and that is/was the intended design pattern. I kind of disagree: it is a shared responsibility that either piece of the User Agent stack can and should manage.

> 
> "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".
> 
> SP: This is an illustration of how browsers may exploit ARIA markup to make
> content available to users. If browsers start doing this, then the mechanism
> provided by screen readers becomes redundant.

Agreed, and/but delivery to "accessibility" does not (should not) be the sole responsibility of screen readers - screen reader users are but one group of affected users.

>  Screen readers have taken the
> lead in exploiting what is exposed by ARIA in order to make content accessible
> to their constituents. Browsers enable AT to exploit the ARIA markup but
> browsers have not gone all out to do it themselves.

Exactly, and so I am question why that is. 

Is it because, as I read James' assertion, they are not supposed to (as far as how the browser vendors interpret the ARIA language under examination), or that so far they simply haven't?

> On the desktop there are several keyboard shortcuts for doing tasks like
> maximizing a window or copy/paste. Screen readers do not ordinarily provide
> keys to do these tasks but list or point to these features provided by the OS.
> Screen readers will do the same if browsers incorporate mechanisms to expose
> content marked up with ARIA.

As ARIA suggests can happen.

> When they do this they will most likely include some visual cues to indicate
> presence of ARIA markup they support.

This statement I am less inclined to believe. James suggests that ARIA, with regard to browser behavior, MUST not change the UI, where-as you have just suggested that it is possible that they might (or should), and I am of the same general mindset.


> With regard to captions : This an accessibility feature that permits captions to be
> shown / not shown based on user's needs.
> With regard to Dragon or modifications made by screen magnification s/w or
> links list provided by screen reader s/w: That is what AT does in order to make
> content accessible. Changing the UI is in fact a significant part of the
> accommodation strategy offered by AT to their users.

Correct. This then leads to the following question: Is ARIA intended for tools, or users? If you have a disability that does not require "assistive technology", then ARIA isn't for you? Should the folks working on cognitive issues (COGA TF) not bother looking at ARIA as a means of addressing issues that affect "their" user-group if those users do not have "AT" installed? This very much seems and feels like the stance being taken - that it is up to Assistive Technology ONLY to make changes to the UI, and for those users who do not have AT installed, too bad, so sad? Ouch!

> 
> Conclusion:  browsers can exploit ARIA to make content accessible to non-AT /
> screen reader users too. ARIA is certainly not meant only for  non-sighted users.

I'll go one step further: browsers SHOULD exploit ARIA to make content accessible - full stop. Linking ARIA to AT is an artificial barrier that does not recognize the fact that not all users with disabilities require assistive technology. We do a dis-service to those users by directly linking disability to assistive technology (ies).

*****************
Meanwhile, James Craig wrote:
> 
> This has been in since the beginning.
> 
> "Aside from using WAI-ARIA markup to improve what is exposed to accessibility
> APIs, user agents behave as they would natively."
> 
> http://rawgit.com/w3c/aria/master/aria/aria.html#ua-support
> 

Hi James,

Interesting, as you and I both quote the same section, yet walk away with different understandings. The entire passage reads as follows:

"1.3 User Agent Support

WAI-ARIA relies on user agent support for its features in two ways:

    Mainstream user agents use WAI-ARIA to alter how host language features are exposed to accessibility APIs in order to improve accessibility. The mechanism for this is defined in the WAI-ARIA User Agent Implementation Guide [WAI-ARIA-IMPLEMENTATION].
    Assistive technologies use the enhanced information available in an accessibility API, or uses the WAI-ARIA markup directly via the DOM, to convey semantic and interaction information to the user.

Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would natively. "

[JF: James, you pointed to this sentence, and specifically to the term "behave"]

"Assistive technologies react to the extra information in the accessibility API as they already do for the same information on non-web content. User agents that are not assistive technologies, however, need do nothing beyond providing appropriate updates to the accessibility API.

The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup." 

[JF: yet in the same documentation I reference this sentence, and specifically "... neither requires nor forbids user agents from enhancing native presentation and interaction behaviors..."]

"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."

*****************
Sitting back and looking at both of these sentences, one difference (amongst a few) that I note is that the sentence I reference uses the words 'presentation' and 'interaction', while the sentence you focused on references 'behave' (behavior), and I suspect that is where the differing understandings manifests. The question then becomes is presentation a behavior? Can we offer up alternative presentations that do not have an impact on behavior? Perhaps more importantly, in the sentence I reference; is 'interaction' the same as 'behave' (behavior)? And if "yes", there seems to be a contradiction in the current spec, as you and I are certainly reading the same text, but walking away with different understandings.

Elsewhere, James wrote:
>
> If a host language like SVG imports and extends the mainstream behavior based on
> an ARIA attribute, then a browser should incorporate the behavior defined by the
> host language. I don't see any objection to this.

This is, I think, getting closer to my point, which is that currently today, it appears that support for ARIA attributes is exclusively dependent on Assistive Technology, and that the browser is a passive actor in the accommodations for some PwD. 

I think this is a problem, and that the *browser* should incorporate directly the ability to leverage some ARIA attributes - and I would suggest that this should be achieved via browser settings. I don't think having those settings start at either "off" or "default" is wrong (in fact I agree that is the proper starting point), but at the same time browsers today are not really doing anything with ARIA save to shuttle it off to the Accessibility API and "good luck". I believe that browsers should carry more water here, and that having built-in settings (like we already do for setting such as font-face and font-size), in the browser, that can leverage ARIA attributes when appropriate, is something that is missing today, and would be a good thing moving forward.

> However, that's a far stretch from what I think John and Sailesh may be proposing.
> I may have misunderstood, but my reading of their emails is that browsers could make
> some behavioral change based on ARIA attributes, even if it is not defined in host
> language spec.

But, that's the point. HTML as a host language doesn't really define any behavioral nor even truly any presentational outcomes, it expresses semantics, which can be modified to meet the end users' needs. 

>From http://www.w3.org/standards/webdesign/htmlcss :

What is HTML?
HTML is the language for describing the structure of Web pages. HTML gives authors the means to:
  Publish online documents with headings, text, tables, lists, photos, etc.
  Retrieve online information via hypertext links, at the click of a button.
  Design forms for conducting transactions with remote services, for use in searching for information, making reservations, ordering products, etc.
  Include spread-sheets, video clips, sound clips, and other applications directly in their documents.
With HTML, authors describe the structure of pages using markup. The elements of the language label pieces of content such as “paragraph,” “list,” “table,” and so on.

What is CSS?
CSS is the language for describing the presentation of Web pages, including colors, layout, and fonts. It allows one to adapt the presentation to different types of devices, such as large screens, small screens, or printers. CSS is independent of HTML and can be used with any XML-based markup language. The separation of HTML from CSS makes it easier to maintain sites, share style sheets across pages, and tailor pages to different environments. This is referred to as the separation of structure (or: content) from presentation.

*****************
If we accept that HTML is for semantics, and CSS is for display, and that ARIA abstracts "behavior" in scripted behavior - and that the browser can adapt the HTML without the use of Assistive Technology to meet the user needs, and CSS can be modified by the end user in their browser without the need for AT, *WHY IS IT* that when it comes to ARIA/behavior, the end user cannot make any UI changes (or even leverage the marked-up attributes) without first mandating inserting Assistive Technology into the mix? (Or, more simplistically, why are we reserving curb-cuts *ONLY* for people in wheel chairs?)

THAT is the question I am posing.

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

Advancing the mission of digital accessibility and inclusion

Received on Monday, 21 September 2015 14:39:46 UTC