See also: IRC log
<scribe> scribe: 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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/problems/problems?/ Succeeded: s/which means we need full built-in implementation of ARIA/Which means right now unless ARIA is mapped to the acc APIs it isn't possible to access it in that browser./ Succeeded: s/ail/fail/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: MichaelC Inferring ScribeNick: MichaelC Present: Joanie Markku JasonJGW MichaelC MarkS Cynthia Léonie John JamesN Shane Janina Hober @@*4 Charles_LaPierre JF dcooney Kenny Dominic Got date from IRC log name: 28 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/28-aria-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]