Breakout Session: WAI-ARIA - Speculating on the Future of ARIA in the Context of Emerging Requirements -- 28 Oct 2015

<scribe> scribe: MichaelC

Framing questions from MichaelC

Questions for ARIA engineering

Is, or should be, ARIA:

* a technology to fill a11y gaps in new technologies

* a replication on the Web of platform AAPIs

* a complete accessible user interface description language

Where a11y semantics exist in other languages, does ARIA need to replicate them?

* Pro: 1 language may have the semantic but others do not

* Pro: Lower learning curve on AAPI with ARIA alone

* Con: There are more ways to do things, confusing for authors and harder for

implementers

Does ARIA have a role beyond providing semantics that map to AAPIs? Or should non-

AAPI accessibility features be provided another way?

Do we expect all ARIA features to be mapped by mainstream user agent, or might some

of them be mainly for scripts etc.? Does that help define what might be an ARIA

feature vs a "something else" feature?

A given feature could be met in many different ways:

* ARIA role

* ARIA state or property

* HTML/SVG/etc. element

* HTML/SVG/etc. attribute

* CSS property

* Media query

* RDFa

* Web Annotations

* JSON

* Web API feature

* Another metadata taxonomy hooked in in some way

* others?

How do we decide which is the optimal solution for a given feature?

There is a lot of interest in de-ghettoizing a11y, both from the process of how we

work with WGs and from the engineering of where features land. How does the future of

ARIA impact that?

Do we have an interest in having a11y reasonably completely defined in one technology

How can we discuss accessibility feature requests, with straw engineering proposals,

without getting lost in engineering weeds before the feature itself is fully vetted?

How can we work now on a vision for the future, without being distracted from the

task of completing ARIA 1.1?

What groups do we need to discuss a new a11y engineering model with?

* Web Platform

* SVG

* CSS

* TAG

Discussion

jf: worried about author fatigue
... how do we teach authors all these things

cn: authors implement via copy paste

with no understanding

we need the ARIA functionality to migrate into mainstream browser

rather than via scripts and hacks

one barrier to this is the way scripting works right now, things would break in some circumstances

jgw: +1

need to balance author desire to create new components, and allow them to do so fully accessibly

with need to standardize stuff as much as possible

when creating new features, need way that doesn´t involve going through a WG and all that stuff to be able to provide the a11y

AAPIs provide this to some extent, but rely on AT implementation

well defined way to extend things

jn: there are ARIA attributes for lots of web authors

and other attributes used only by specialized component developers

the first set needs a full equivalent in host languages

<mhakkinen> +q

the ARIA version should be available for those who want it, but the host language version should be preferred by the masses

lw: right now can´t access DOM in some browsers

Which means right now unless ARIA is mapped to the acc APIs it isn't possible to access it in that browser.

cs: could provide access to DOM

lw: would like a testing effort to identify gaps in host languages

and where things could be fixed with existing features

jf: the I in ARIA is for Interaction

the Web isn´t a document medium anymore, it´s a platform for sharing and posting

do we want to sequester ARIA to interaction, and solve other problems in other ways?

or use ARIA to solve other problems?

right now there are lots of user groups not well addressed by ARIA

concerned that browsers see ARIA as something that is handed off to AAPI

and that´s that

think we need more than that

how do browser vendors see ARIA?

cs: we see ARIA as a way to expose AAPI to developers

with complex applications, I´ve heard developers would rather do all one thing

all ARIA, or all native, rather than a mix

re implementing other stuff, if it works with the AAPI, yes

<scribe> chair: Markku

complicated to answer from other scenarios

the COGA proposal doesn´t feel like a natural fit to ARIA

I had viewed it as a peer to ARIA

we´re talking about more robust extensibility mechanisms for ARIA 2.0

to describe behavior not just identity

cn: the options are div soup + ARIA, or HTML 5

if you do div soup, ARIA has to address all the needs

then you have developers copying lots of script just to implement e.g., a button

why not just a native feature with all the AAPI and interaction features built in?

circle back to existing content would break

if UAs started providing native support for ARIA features

such as adding native interaction to an ARIA button, which also has script attached to it

and browser can´t reliably turn the script on and off

mh: for assessment, there are a lot of innovations taking place

that are well understood in that space e.g. by teachers

have HTML 5 implementations, good keyboard support, etc.

but struggling with how to describe the visual affordances non-visually

there is noise from the GUI lens of looking at things

the descriptions of objects are the noise

cs: using name doens´t work?

mh: role description gets us part way there

also want state description

and have it ubiquitous in AT implementation

cs: this is a choice the AT makes?

mh: would be great if the AT didn´t have to do anything

jn: if you say this is a pizza, how does the user know what they can do to it?

mh: in an assessment exercise, an available action might be ¨take slice¨

jn: but that´s no a known operation

mh: right; we want that in the description

jf: what do we mean by AT?

screen readers?

or inclusive of other

mh: also readaloud tools

cs: people with different disabilities have different needs

mh: which is part of the learner profile

that impact how it´s customized

which matches with the COGA model

ms: we have to consider localization factors

cs: UIA has a localized control type

ms: in assessment context, there is tight control

cs: are standardized tests available in other languages?

mh: most are

cn: if ARIA is a patch language rather than a holistic one

it doesn´t try to compete with other languages

if it competes with some piece of HTML or SVG

there could be different ways to do the same thing with different outcomes

e.g., the ARIA way works in AT but doesn´t have interaction built in; HTML way has interaction but not AT

then somebody gets screwed either way

so replicating functionality is a big architectural fail

jd: ARIA is out there in the wild

sometimes being used in unexpected ways

but gotta support those uses

once they take hold

example of Google Docs that pumps info to screen readers via live regions

jf: for screen reader, I understand this

but want to question ¨ARIA is great for screen readers therefore ARIA is the way forward¨

it might not address all user needs

jd: clarify that ARIA isn´t just for interactive any more

I´m not advocating a direction, but need to be aware of what is happening

js: initially ARIA was a patch

we intended it to have a limited life

<Zakim> JF, you wanted to point to track element as a more mainstream solution

but it became evident that it was a useful way to fix bad pages

so now we want to use it as a way to push things into AAPI

such as current efforts with DPub

DPub expects the ARIA roles to be mainstream in the Epub context

we don´t know how to do all of that yet

jf: have we have a robust discussion with browser vendors

that this is a direction that will work for them?

solving for EPub readers is great

but will it fragment if the web browsers don´t take it up?

js: are you saying if it doesn´t go in mainstream browser, we shouldn´t do it?

various: no

lw: @@

js: it will help for us to explore the concepts outside of the final engineering proposal

some of the solutions may come from here and some from there

jf: so let´s clearly define our problem statements

and discuss solutions with others

<mhakkinen> +q

worried about trying to engineer aria-supersolution

js: think we´ll be able to shift the engineering proposal from COGA

dc: Dominic from Blink

there are ways to engage with browser developers without being a supplicant

Blink is developed by a lot of different developers

with various background knowledge

with screen reader bias because it´s something they can get their heads around

a11y engineers have to work within larger project plans

so would help to bubble things up there

jf: it´s common that people without deep a11y expertise focus on screen readers

I do want to communicate that there is a deeper picture

and question whether ARIA is the solution in all cases

mc: interesting parallel between defaulting to screen readers, and defaulting to ARIA

dc: there isn´t a concern per se of HTML native vs ARIA

but whether there is a single clear place that it´s spec´ed

would be good if there was layering where accessibility features of HTML were expressed in terms of an accessibility spec

so there is no duplication

right now ARIA isn´t expressive enough to play that role

jf: do we want it to be?

or do we want it for other things

dc: with web components coming, having a way to do that extensibility would be really valuable

cs: not sure it´s bad for there to be differnt ways to solve a11y problems

cn: is bad if they conflict

Breakout Session: WAI-ARIA - Speculating on the Future of ARIA in the Context of Emerging Requirements

28 Oct 2015

Attendees

Contents

Framing questions from MichaelC

Discussion

Summary of Action Items

Scribe.perl diagnostic output