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

> On Sep 21, 2015, at 7:39 AM, John Foliot <john.foliot@deque.com> wrote:
> 
> TL;DR
> 
> If we accept that HTML is for semantics, and CSS is for display, and that ARIA abstracts "behavior" in scripted behavior

There's your mistake. ARIA doesn't abstract any behavior. It only tells the APIs the current state of controls whose behavior is maintained by other technologies, primarily HTML and JavaScript. 

This is why @tabindex, KeyboardEvent, FocusEvent, and other behavioral features critical for an accessible interface are not part of ARIA but instead defined in the appropriate related technology: usually HTML, DOM, CSS, or ECMAScript.

> - 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,

If you're referring to User Style Sheets...

> *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)

The User CSS equivalent for this is something like greasemonkey scripts, which are available in all browsers through add-on interfaces.

> without first mandating inserting Assistive Technology into the mix? (Or, more simplistically, why are we reserving curb-cuts *ONLY* for people in wheel chairs?)

Your metaphor is dramatic, but inaccurate. Real world curbcuts are part of the mainstream interface. The web equivalent of that is to work accessible interfaces into mainstream features... In this case, that mainstream feature is native HTML drag&drop, not the ARIA retrofit.

To correct the metaphor: we're trying to build the curbcut; quit trying to mandate a wheelchair escalator. ;-)

James

Received on Monday, 21 September 2015 17:44:17 UTC