ARIA Working Group -- 23 Sep 2016

<richardschwerdtfeger> trackbot, start meeting

<trackbot> Meeting: Accessible Rich Internet Applications Working Group Teleconference

<joanie> scribe: joanie

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/wiki/ARIA_2.0_Issue_Triage

TAG Review - ARIA

RS: A few months ago we met with TAG and talked about issues we want to address in future ARIA work.

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/wiki/ARIA_2.0_Issue_Triage

RS: We also had a list of issues for ARIA 2.0 (url above)
... Some of these issues will be addressed by AOM.

Alex: I understood that earlier in the week, there's an agreement to get full parity with HTML and ARIA.

I've also worked with Alice Boxhall.

Is there a proposal for extensibility?

<tzviya> s/Fixme/Alex

RS: We've not yet looked at role extensibility yet.
... We've started a thread on github regarding control patterns.
... I don't think that will be enough to get us there, however.
... Control patterns is not currently in the AOM roadmap.
... I think for first steps, we have getting the additional roles in for web components.
... AOM and query selector can be used for this.
... They also allow for accessing elements as objects rather than element id.
... The next release of AOM is supposed to be out in a year.

Alex: How will that work with AOM (computed role name)?

RS: ARIA can take multiple role values.
... Whichever one wins will be the computed role.
... But the role will not be what you get at the platform level.

Alex: I understand that AOM is the computed output of style information, DOM information, ARIA information, and script that you modify it with.
... I'm trying to understand what authors will get as a result.

RS: This will also help with automated testing.
... Something else we're going to have to look at is generated content.
... We can get at it via the accessibility API, but not from the element itself.
... Some people have been making great progress with automated testing.
... So the CR cycle will be much, much shorter going forward.
... I'd like to hear your thoughts on accessibility.

Alex: I'm putting my designer hat on.
... Today we have a fixed vocabulary, which we currently extend.
... In web components, we were seeing people extend through javascript, divs, spans, etc.
... We have tag names in the document, and a table from which you can look up names and values.
... All custom elements require a dash in their name.
... It's posible for authors to create a whole world of elements with no overlap.
... When an element is created, the parse finds it in the document and decides what to do.
... In the case of custom elemnts, we need to wait for that element's definition to load.
... From there, how do you inform the system regarding what to do?
... In ARIA, it's well defined, so you have cross-platform/API behavior.

kirkwood: That's where I would start, anyway.

RS: We talked about control patterns from UIA.
... They have a combination of properties and functions.
... So I can know if they are clickable, scrollable, etc.

<MichaelC> scribe: MichaelC

<dbaron> ScribeNick: MichaelC

ar: for web components we saw developers rebuilding their own component model

is there exploration in how frameworks are building higher level behavior for ARIA today

rs: no

ar: would be a good exercise

ls: first set of roles 10 years ago anticipated RDF

so taxonomy intended to allow people to create their own roles

but that never took off

the background in the taxonomy never took off

ar: was the processing designed?

rs: were working on it, namespaces fell out of favor, ...

people weren´t working on it

tz: tried recently

can´t extend via RDFa

rs: we could revisit that

ls: would be good to go back to that

rs: would browser vendors want that?

ar: don´t think so

do we know what developers are asking for?

rs: we´ve been asked for extensibility

haven´t collected comprehensive use cases

need to do that

our top priority is roles

ar: excited for reconcilitation of ARIA & HTML

rs: the automated test harnes will save us a lot of time

<Zakim> tzviya, you wanted to ask about creating terms without API mappings

tz: for publishing, there is processing that maps to what user needs to understand

e.g., I´m in a chapter, not a chunk of stuff

going forward, working on assessments for a learning management system

need to know I´m using a multiple-choice question, not just a question

not a candidate for core ARIA vocab

have explored list of roles without AAPI mapping

might have <p role=¨multiple-choice¨>

mk: what is difference from that and using roledescription?

rs: two kinds of extensibility

there are custom widgets, making discoverable

then there is extending taxonomy without worry about mappings

mk: AT localize role strings

if they don´t want to call an article an article, they don´t have to

they are responsible for localizing

author must localize roledescription

clp: could you navigate among questions using roledescriptions?

mk: question of underlying semantics

question of whether user knows what they are so they know to use e.g., next element, next region, etc

rs: so don´t map stuff that doesn´t have value to AT

jgw: 2 kinds of extensibility

define new widget composed of familiar properties and behaviors

vs something genuinely novel, can you declare what it is, how to interact, what operations it supports, their effects, etc.

for educational applications some could be handled by first kind of extensibility, others by the second

mk: with right primitives you should be able to make anything

jgw: depends on what they are

if you could define arbitrary operations, what they´re called, interaction model for its input device

that´s pretty low level

vs something that accepts text input or something, where you don´t need to define elementary behaviors

there may be a continuum, but see these as distinct

rs: need device independent interaction

adding keyboard support is the most costly thing of creating a component

would be a lot easier if we could abstract and push that to the browser

define a common pattern

is TAG looking at that?

ar: no

some work on bundling up apis

that can make packages of accessible behavior

might relate to web components work, we should discuss with them

rs: accessibility been issue since 2002 in that

can we explore?

ar: TAG role is to facilitate conversation

rs: device independent interaction will be most positive thing going forward

mc: are there open questions about ARIA WG plans?

ar: full overlap between HTML and ARIA proposed for 1.2?

rs: not sure which version, may require refactor

ar: so soon but not immediate

then, extensibility

db: what is full overlap?

ar: ARIA role and state mappings exist to HTML features

there are HTML features that don´t have corolaries

like p, blockquote

db: ok so features that exist in one

mc: there isn´t consensus how far to go, do we map div? some say yes some no

ar: need to refine the plan then

<richardschwerdtfeger> taking a break

<scribe> meeting: ARIA FtF Day 2

<janina> scribe: janina

TAG Debrief

[Discussion of whaqt topic to take up when]

JasonJGW wants to discuss use cases related to extensibility -- probably 13:30

rs: Web Components wants an ARIA role for all HTML semantics ...
... This will require ARIA spec refactoring, as it's a lot of stuff

jd: A lot of roles, yes, not sure how best to approach

rs: a module?

jd: we don't need to decide yet

jc: Let's not wait too long, when we're really overloaded on roles

jd: Let's wait until we have physical document issue to solve

rs: I'm disinclined to go for a monolithic 2.0, prefer incremental releases that come quicker

<mhakkinen> +1 to faster, modular releases

fb: Perhaps feature releases would help us get revs out more quickly

mk: e.g. select a feature or two, spec them,get them out
... Couldn't the extensibility piece be its own release?

rs: Could
... Lookingat the things that slow us down, automated testing is no longer a problem
... But, we would have to refactor 1.0
... That means enough people to work on it ...

mk: Whatever it takes to reduce the overhead that gets us to smaller, quicker releases
... We also don't want people waiting forever for critical pieces

rs: e.g. static role

jc: If quick releases, in AOM we've set up explicit scope per release
... e.g. media controller, only webkit implementation, amazing a11y use case for description, captioning, etc
... not picked up outside of webkit
... That took it out of the spec
... Think this group lacks that kind of process discipline
... That kind of discipline is the only way to insure fairness

jc; Clearly, we all want inclusion, but we can't get everything

jc: Expect we might maybe get to a point where there's enough change that we just call the next release 2.0
... My proposal for 1.x that we define inclusion/exclusion criteria
... In AOM we require all platforms support
... What's the bare minimum that we can ship and still deliver benefit

<jcraig> HTML module: html-prefixed 1:1 role mapping

jc: For 1.2 proposing html module and ...
... for 1 to 1 mappings ...
... also ambiguous roles, like frameset, script

<jcraig> HTML support: "generic" role for HTML support

jc: generic role, div span, etc

<jcraig> maybe HTML support: ~"custom" role for HTML support for uncontrollable elements

jc: could use in the interim for video

<jcraig> Errata: "static" role to match previous (existing) implementations of text role.

jc: should be subclass of image

<Zakim> jcraig, you wanted to suggest a scope for ARIA 1.2

mk: that's a lot
... agree we should have inclusion/exclusion discussion, but should do it before we go into specifics of what might, or not be included

jc: Also need a narrow scope along with inclusion/exclusion

mk: those topics are not criteria
... that's a feature scope proposal, not criteria
... having existing implementations is clearly good
... but what if there are no implementations but wide agreement something is really important?
... we need to map out the future as well

<richardschwerdtfeger> q/'

mk: suggest we need to lay out a map for the future as well as the specifics of the next release

<Zakim> jcraig, you wanted to mention inclusion criteria is 1. HTML role parity, 2. The one or two ARIA roles, we need to support HTML role parity, and 3. Errata (mapping things that exist

jc: repeating ...
... but also errata
... i.e. get a match to today's implementations
... these are items in previous drafts that we pulled ina way it's hard to get a replacement in

rs: don't understand your custom role

jc: yes, not a great name
... we need to deal with nonrendered tags, div, style

rs: are cusom complenents going to use generic roles?

mk: screen readers do reneder div and font differently

<Zakim> MichaelC, you wanted to ask about aspirational speccing vs reflective speccing

jc: we need to solve this to have html one-to-one parity

mc: it's always a challenge to distinguish between reflective and aspirational specs
... we've been aspirational
... but if only reflective we may not meet our mission on a11y
... i want a sense of the appropriate balance

mk: if only reflective then non browser people are at the mercy of browsers

<Zakim> jcraig, you wanted to discuss aspirational

mc: whatever balance we choose, we would need a way to know we're holding to it

jc: agree that some things that have happened would not have happened had we not been aspirational
... but sometimes we think if we get that in the spec, it will force implementations
... perhaps sometimes it does
... aspirational features should get more buyin on the way -- that it's worthy to pursue
... need to be sensitive to what is, and isn't technical solvable
... consider UAG, almost nothing in the browser, but most achievable with styling
... the UI of AT, as of the browsers, varies as a way to draw users

<Zakim> MichaelC, you wanted to say prepend use case documentation to requirements gathering

mc: also formal use case documentation earlier

jc: also scoping use cases, indieui was too huge

mc: i'm ok with wide open use cases, but filtered and disciplined in our choices of what to spec

mk: i like that

jc: we also need more end author buyin. we have implementors and users, but need authors

rs: we need at vendors involved

rs some of us need to go out and get them directly involved. we should not have to chase them

rs: this is part of getting things done faster

mh: so we have three ...

mk: apple, microsoft, google, linux
... not the big market share

mh: how to get them to the table?
... asking dept of ed in U.S. to pay to get them into TPAC

mk: it's the amount of time, not just the TPAC week

jc: don't believe you're suggesting U.S. pay for Freedom Scientific, perhaps though NVDA is worthy
... the call is an hour i'm not doing something else
... css is doing this, moving to github issues instead of weekly telecons

mk: perhaps worth discussing that specific topic

jc: maybe an github issue, with a set of tagsets to track implementation

mk: but their inmput might have changed hat we spec'd

rs: I'll talk with NVDA and FS and see where we get
... we are moving to github

jc: maybe github will be enough

mk: implicit could be serious issue

jc: my proposal is that it works as today

rs: now looking at correct pronunciation issue -- how do we move forward on that
... it's not html parity
... is there an agile approach

jc: suggest file bug on webkit, also other platforms
... once there's a browser implementation, put up a web page that shows the issue clearly

[the page of shame]

rs: suggest work that in parallel.
... if it transpires there's something for aria, we'll have more info on what that is

jc: proposes an immediate CfC on 1.2 scope
... html parity and static

rs: remember we have an HTML AAM

mc: but often fuzzy
... what about input control types, which is how we got into password discussion
... we're sorting priciples of what goes into dot next

rs: we need to coord with web componenets

jc: maybe we don't have to complete html parity in 1.2

mc: does the timjeline win? anything not ready moves to noext rev?

rs: I think yes

jn: then we never get to the big stuff for 2.0

mc: wcag is trying this, point releases plus major release
... we'll see how it goes

mc; worried a bit about the cost of dot release

mc: seems from fpwd to tr is no less than 8 months

<Zakim> janina, you wanted to suggest as needed involvement is the enemy of quick and frequent specs

janina: needs to be accountability and participation for decisions, so as not to revisit issues especially when releases are calendar driven

jc: I suggest you bring people in with the carrot, not the stick.

mc: agree with different individual priorities, but there's also the commitment to the group that should be part of that

<MichaelC> because it complements their priorities

mc: there has certainly been much concern about how heavy our process is
... on the one hand it's how we insure fairness
... on the other hand, we don't want to be burdensome
... asking for level of participation so we don't have to revisit issues needs to be part of that

joanie: want to get back to inimumj w3c fpwd to tr timeline
... maybe we want to better organize ourselves, so that possible features aren't in the draft spec so long that people implement before we've actually decided it's a spec feature
... suggest 1.2 1.3 1.4 without finalizing, ut 1.5 goes tr
... we need to tell implementors that we won't pull the rug out, we promise you can use this

lisa: we did that with 1.0
... suggest new things be also fit into the ontology as a sanity check

rs: we do that

lisa: maybe a tf for 2.0
... perhaps could start with requirements

mc: if we did that we would probably want the tf scoped to the architecture

mk: could we define stages for each element of work
... design, ready to implement, has two, ...
... actually so laeled in the doc
... making it clearer what stage each piece/feature is at

jc: sounds like a living standard

mk: pull the implemented and tested into a point release

mc: haven't been convinced that living standards are a good idea

jc; and when you have two to keep in sync

mc: we had the "already implemented" problem in 1.0

joanie: something i'm trying to avoid

mc: especially the web page implementation then the browsers change

mk: labeling stages also helps spec development because authors could knowlingly help us evaluate that value of features

mc: our risk assessment will be aided by auto testing

rs: we still need to figure out a reasonale timeline for html parity

mc: many things to sync, spec, aam, apg

mk: once the apg is up to date, should not be hard to keep it updated

rs: how much time to catch up with html parity

jn: we're not writing that

jc: maybe an example of how to point to it

rs: also want to sync up with aom

jc: don't know

rs: can we assume end of 2017?

<jnurthen> scribe: jnurthen

JC: would like it to be closer to match orientated

RS: where would we need to cut next year

if targetted for end of next year... would we need to cut in July?

MK: talking about a timeline b4 the criteria?

RS: think we should set timelimits on things
... want to avoid massive wordsmithing during meetings

MK: want to set some expectations about cadence

<jcraig> AOM editors don't need "HTML Role Parity" for AOM... That need is for Web Components, particularly the "default role per Web Component" idea being discussed in Web Platform.

want to be able to get spec text done in 6 months

RS: not saying what will be in the content

MK: need some consensus on inclusion/exclusion

RS: when do we need to cut it off

JC: can't do timeline without knowing what exclusion/inclusion is?

RS: need to put out for CFC

JC: no point in timeline now if don't know what the criteria is

MK: if know from the beginning need 2 implelementions - time in CR could be less

JC: the thing I am talking about - assuming it works the way I expect it would be a trivial change in webkit and chrome - would just be dropping synonymns into the role mapping

all the roles are there just not exposed as aria standard roles

RS: why don't we break - add a proposal and people can weigh in on the 1.2 release

had other things in the 2.0 release too - what else is critical

MK: may also look at what 1.3 may include and get people focussed on that

maybe 1.2 in 2017, 1.3 in ....

RS: lets have that discussion this PM

CLP: want to bring up the process thing. have tasks in process and then move between sections

<jcraig> The "HTML Role Parity" is also for test tools, like the Accessibility Node panel in WebKit Inspector, or the Chrome Accessibility extension (cc ABoxhall), or Microsoft's F12 Dev Tools (cc JoshJansen)

there is a lead assigned - with dates and tasks etc. then would be able to have a visualization as to where things are so can get things forward

JC: the churn doesn't happen in the spec but in github

there are even tags for sections of features

RS: need to figure out what we are working on

JC: if something is ready put it in.....

<mhakkinen> FYI… Press release from W3C on TPAC. ARIA gets a mention! https://www.w3.org/2016/09/tpac2016.html.en

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/wiki/ARIA_2.0_Issue_Triage

<Lisa_Seeman> Scribe:Lisa_Seeman

Triage

rich: lets identify what we cant live without, and priortise

cant live without: html parity

<richardschwerdtfeger> s/treage/triage/

Handle multiple role values: may have been dealt with

allow properties to be accessed as DOM properties -that is aom

james n to add this to the issue

Support selectors is also aom

Get computed role or name also aom

(selectors can be aom as well)

Role extensibility

matt: wasnt this extensibility

what we were dealing with

rich: yes bit non urgent for now

non argent: State and property extensibility

assign ARIA semantics and event handlers

support CURIE

handle disabled script

control patterns

is aom

and extentsality (matt)

so that is 2.0

non urgent forward compatibility

getting adressed now host language default mappings

issue 55 is being done now

(aria 1.2 bucket)

sync similar attributes from host language and ARIA

joanie: nwhy is this not part pof parity

JamesN: this is browser syncing real time. it should be closed

janina: worht a discussion later

conclusion 2.0 bucket

matt can we get rid of aria hidden in the long term

as a 2.0

for later discussion

next tell author what is host language role (ISSUE-467 is aom

full xlink behavior in link role

(this is svg)

2.0

input types is 1.2

SVG stuff is 2.0

( provide SVG implementation guide (ISSUE-339) (now under way) navigational landmark labeling (ISSUE-341) shadow trees (ISSUE-342))

Allow AT to modify DOM (ISSUE-461) and

Semantic zoom (ISSUE-469) is 2.0

Refine AT requirement

joanie: we cant use must anyway

i like shoulds

for screen readers

Matt: james also likes should, but when there is nothing about at it is not good for them

close ISSUE-525)

<trackbot> Closed ISSUE-525.

Provide error handling guidance -

joanie: i is hard to do reliably

all bets are off

for AT

Matt: this is not a dsingle issue

so it is 2.0

create AT conformance requirements 2.0

michael: it would be better if at had conformance

it should stay on the table

rich: so 2.0

jcraig: is the a example of a must for all AT always that we are not doing

rich: example from leonie, the statis that is is currwnt at the end of the string

every: but that is a user prefrence not a must

(everyone)

matt: must for at - what is that, that an at conformas?

(aom is accessible object model thign that james showed us)

michael: password role. and that was the problem

so we should look at it for 2.0

2.0

richardschwerdtfeger: 1045 just opened

it's won buckety?

will be prototypes for now

mhakkinen: will prototype

we dont know it might be 1.2, if at all

richardschwerdtfeger: aria-activedescendant we have

lets close

close ISSUE-560)

<trackbot> Closed ISSUE-560.

implicit aria-level in treeitem is realy hard

james AOM will make it easier

Michal should re retag thisng for aom

close ISSUE-612)

<trackbot> Closed ISSUE-612.

Datatypes and formatters (issue 51)

<jcraig> ISSUE-51?

<trackbot> ISSUE-51 -- How should we address the issue of datatypes and formatters in ARIA? -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/51

richardschwerdtfeger: are we doing this somewhere

coga should look at it

<janina> scribe: janina

rs: Closing issue-51

issue-406?

<trackbot> issue-406 -- Proposal for new aria-hint property. (Previously proposed as @aria-help) -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/406

<Lisa_Seeman_> scribe lisa_seeman_

<Lisa_Seeman_> rich: we pushed this off

<Lisa_Seeman_> micheale: it helps meet a sc in wcag

<Lisa_Seeman> Matt howle space ff mapping error messages

<Lisa_Seeman> depends on the ui

<Lisa_Seeman> guidnece to at?

<Lisa_Seeman> rich: we have details decribed by and more

<Lisa_Seeman> mat: room for more

<Lisa_Seeman> Lisa: coga has this one. we just need to check we cover this use caase too

<Lisa_Seeman> 2.0

<Lisa_Seeman> ric 2.0

<Lisa_Seeman> richardschwerdtfeger: Input hints (ISSUE-406)

<Lisa_Seeman> what is this?

<Lisa_Seeman> 2.0

<Lisa_Seeman> lisa: can we tag it as coga

<Lisa_Seeman> michael: bad process -

<Lisa_Seeman> button types (ISSUE-1)

<Lisa_Seeman> !!!

<jcraig> issue-1

<trackbot> issue-1 -- Add button types to post 1.0 ARIA -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/1

<Lisa_Seeman> lisa: coga might want it

<Lisa_Seeman> jamesk: take by case by case as they come

<Lisa_Seeman> rich close it

<Lisa_Seeman> close ISSUE-1)

<trackbot> Closed ISSUE-1.

<Lisa_Seeman> Default button (ISSUE-624)

<jcraig> issue-624?

<trackbot> issue-624 -- Primary Action Concept -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/624

<Lisa_Seeman> Lisa: this all ovelaps with coga

<Lisa_Seeman> matt is this scoping

<Lisa_Seeman> jason: if it the defualt for a compnent do we need the scope definded

<Lisa_Seeman> maybe limit to dialig

<Lisa_Seeman> AT users dont know how to get it, low value

<Lisa_Seeman> james K : i thought this was an event. we should change the name

<Lisa_Seeman> could be a sub role

<Lisa_Seeman> jonie: can the roles change in runtype

<Lisa_Seeman> james: yes

<Lisa_Seeman> Lisa: ug

<Lisa_Seeman> we should keep it

<Lisa_Seeman> (james N)

<Lisa_Seeman> jcraig: Mozilla had it as an proposed attribute on HTML:button [default?]

<Lisa_Seeman> jason: if it getis into an html spec it becomes a parity issue

<Lisa_Seeman> 2.0

<Lisa_Seeman> Keyboard help (ISSUE-631)

<Lisa_Seeman> rich: non critical

<Lisa_Seeman> jamesK: isnt this result

<Lisa_Seeman> (sorry jcraig )

<Lisa_Seeman> matt this is like aria help

<Lisa_Seeman> rich but we have in aria 1.1

<Lisa_Seeman> mat: but that is same bucket but not the same

<Lisa_Seeman> jason: not quite the same. binding mnemonics

<Lisa_Seeman> tyope tings

<Lisa_Seeman> james:

<Lisa_Seeman> jcraig: i do not intent to block aria shortcuts but

<Lisa_Seeman> it is bad

<Lisa_Seeman> keybords in diffrent locals shift

<Lisa_Seeman> googles can solve for locals

<Lisa_Seeman> but no oe else will

<Lisa_Seeman> we dont even understand it

<Lisa_Seeman> matt: we get it but not this issues

<Lisa_Seeman> jcraig: it is bad for aria cleaness

<Lisa_Seeman> jamesn: it is only documenting what people do today

<Lisa_Seeman> if i hacve it dosumented in a help or in our shortcuts, it is wrong anyway

<Lisa_Seeman> jcraig: it is exposed anyway

<Lisa_Seeman> jamesn: it is only documenting what

<Lisa_Seeman> we do anyway

<Lisa_Seeman> matt: all at have a shortcut to find the short catt, and that depends on the native property

<Zakim> joanie, you wanted to say this F.S. "help" request is tutorial messages for the focused item

<Lisa_Seeman> add jponie to the que

<joanie> https://www.w3.org/WAI/PF/Group/comments/update?comment_id=363

<Lisa_Seeman> jonie: freedom these are not mnomics, these are mnemonic keys

<Lisa_Seeman> they are specificly for AT and should not be here

<Lisa_Seeman> jamesn: doesnt discribe override

<Lisa_Seeman> andthen u have two things

<Lisa_Seeman> lisa: codinate with coga personlisation

<Lisa_Seeman> janina: can we move to 2.0

<Lisa_Seeman> jcraig: we have api that is closer to AT wants but not specific for keyboards- we would need an event model backing the help

<Lisa_Seeman> matt: extecibility bucket?

<Lisa_Seeman> jamesn: need to know the model for support. if ti is the event model it is more like controls

<MichaelC> scribe: MichaelC

rich text editing (issue-92) leave to web platform; close

<jcraig> issue-104

<trackbot> issue-104 -- how to communicate form autosubmissions to a user -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/104

<jcraig> close issue-104

<trackbot> Closed issue-104.

<jcraig> issue-384

<trackbot> Sorry, but issue-384 does not exist.

issue-381

<trackbot> issue-381 -- Keyboard support across platfroms -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/381

<jcraig> related issue-352?

<jcraig> issue-352?

<trackbot> issue-352 -- Address device independent interaction with widgets -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/352

mck: this is an author concern

not for ARIA to solve common keyboard

issue-639

<trackbot> issue-639 -- Making key events work automatically on focusable elements matching certain roles (e.g. button, link, checkbox), that have click event handlers -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/639

jn: nice in principle but too many places it would break things

jc: @@

issue-349

<trackbot> issue-349 -- Specify actionable elements -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/349

rs: leave open

mck: isn´t this related to @@?

issue-445

<trackbot> issue-445 -- Support Control Patterns in ARIA -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/445

jc: these two are related

jn: this was to address older AAPIs that didn´t know how to address aria-sort

close 349

jc: 445 is WAPA

rs: leave that one open

for now

issue-569

<trackbot> issue-569 -- Introduce an ARIA attribute to indicate a column is sorted -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/569

jc: sortability @@

jn: multiple arrows show sort on multiple columns

this isn´t important, AT could get the info

issue-96

<trackbot> issue-96 -- Add ability to indicate sort by multiple columns with precedence information -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/96

<jcraig> close issue-569

<trackbot> Closed issue-569.

mck: you can indicate multiple items as sorted

just hard to figure out what is sorted where

leave open

issue-524

<trackbot> issue-524 -- Consider expressing the "sortability" along with the actual sort - ARIA 2.0 -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/524

something we want, though not right away

leave open

issue-603

<trackbot> issue-603 -- Need an attr to indicate element activation triggers audio, video, etc. -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/603

jc: control to help @@

can have voiceover still talking when starts playing

rs: leave for later

issue-634

<trackbot> issue-634 -- Video and audio roles (simple groups, not full functionality apis) -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/634

issue-347

<trackbot> issue-347 -- Investigate adding audio and video element support -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/347

rs: could fit into HTML parity

ok, 1.2

closing the dup

issue-519

<trackbot> issue-519 -- Consider removing aria-level from grid (already allowed on row) -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/519

mck: only in treegrid

jc: allowed on row

in treegrid, but should not be on grid

essentially errata, not priority

rs: for 2.0

issue-337

<trackbot> issue-337 -- Explore whether to have expandable columns (not just rows) -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/337

rs: for 2.0

issue-671

<trackbot> Sorry, but issue-671 does not exist.

issue-371

<trackbot> issue-371 -- Need equivalent for thead, tfoot, and tbody -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/371

rs: move to 1.2

issue-611

<trackbot> issue-611 -- Support Pivot Table functionality in ARIA -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/611

jc: don´t need special roles

just use rowgroup

rs: don´t we want explict mapping to the HTML roles

jc: mappings can cover it without new roles

this dups parity

rs: close

let´s file an issue for HTML parity

issue-1046

<trackbot> issue-1046 -- HTML Parity -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/1046

issue-593

<trackbot> issue-593 -- Reflect the fact that browsers are now exposing child content for things like sliders, separators, scrollbars (childrenarepresentational) -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/593

rs: close, dup

or OBE

issue-351

<trackbot> issue-351 -- Address unbounded numerical values with author specified increments -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/351

issue-718

<trackbot> issue-718 -- Need to allow scrollbars to specify an unknown value for aria-valuemax -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/718

jn, jd: think we addressed

jn: think can close

jd: horse died months ago

rs: close these

issue-539

<trackbot> issue-539 -- aria-valuestep -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/539

rs: needed

jc: HTML parity anyways

rs: 1.2

issue-1027

<trackbot> issue-1027 -- Introduce an aria-valuestep property for range widgets such as a slider -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/1027

dup of 539

issue-411

<trackbot> issue-411 -- Consider aria-description which would take a string like aria-label -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/411

rs: <has a heart attack>

we´ve done what we´re gonna do

issue-437

<trackbot> issue-437 -- Text alternative computation likely to need clarification for HTML5 -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/437

mc: move to HTML-AAM

MICHAEL REMEMBER TO MOVE THIS TO HTML ISSUE TRACKER

issue-360

<trackbot> issue-360 -- Text equivalents in SVG -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/360

rs: OBE, close

issue-470

<trackbot> issue-470 -- We need a caret role for cloud based editors -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/470

mck: close with rich text editing

rs: this came from canvas

let´s see what ¨they¨ figure out

afraid it will get raised again

mck: let it, but close for now

jc: we don´t represent caret in AOM

rs: close

issue-468

<trackbot> issue-468 -- Create ARIA role for figure or other image groups (including SVG) -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/468

rs: done

issue-655

<trackbot> issue-655 -- Consider creating annotations roles for comments, spell-check errors, etc -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/655

mc: do we need this? there is a spec

rs: not sure what we need

let´s leave open for now

issue-685

<trackbot> issue-685 -- Creation of resource definitions for localized state information -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/685

mh: we do want this

jgw: would like to do in >1.2 <2.0

issue-742

<trackbot> issue-742 -- Introduce the ability to provide the destination context of a link -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/742

rs: personalization semantics

<mgylling> is coga and dpub doing link destinations the same way?

mg: thought there were dpub requirements

tz: roles like noteref etc.

mg: ok, so covered, can close

rs: close

issue-29

<trackbot> issue-29 -- Express media types in which roles allowed -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/29

rs: covered by other issue

issue-118

<trackbot> issue-118 -- identify objects that are moveable (such as the split pane separator) -- raised

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/118

jc: for 2.0

<David_macdonald> Test

<David_macdonald> Issue 118 identify objects... leave ooen

<David_macdonald> Scribe: david_macdonald

Close 434 issue

Issue 1036

Leave 1036 open

For issue 335 bread rubs, good idea ...put to 1.2

S/rubs/crumbs

Move to 1.2

For issue 340, scrollable regions

Can be done with css mapping spec,

RS previous lines above

PUNT ISSUE 340 to CSS mapping

For issue 361 HTML <p><em> will all go to HTML parity 1046

For issue 425 css name computation... modalities other than screen modalities... one accessible name for one modality and another name for another modality

Move to 2.0

For issue 536 aria discoverable... close it

For Issue 567 css generated content, punt to CSS task force

For issue 660, implicit labels for region headings OBE because a label is not required on a region

Issue 667 page title role, could be in 1.2 for parity with HTML also... this exists in dpub

<MichaelC> https://www.w3.org/TR/dpub-aria-1.0/

Move issue 667 to 1.2

For issue 670 leave there

FOR ISSUE 1022 this is a 1.2 issue

FOR ISSUE 1035, do we need extra roles and properties for complex than tree widgets

MK. Punt to 2.0

FOR issue 463

Asking for more hidden... punt to aria 2

FOR ISSUE 466

clearly defined weak roles... leave as is

FOR ISSUE 494 says menu is a form control

Not a valid concern because menu is an abstract widget role

Punt 503

Move from triage to James presentatijon

<mhakkinen> LInk to University of Colorado PHET Science Simulation Task: Balloons and Static: http://www.colorado.edu/physics/phet/dev/html/balloons-and-static-electricity/1.2.0-reader.5/balloons-and-static-electricity_en.html

I MS task force a responsible for 3 inaction types. The question arise does aria fit well to describe various widgets. Some users would like more extensibility for aria, not restricted to educational setting

Peter is a list type widgets where you are supposed to reorder the list as in a test

Interaction type, user has to establish relationship between two characters...

S/Peter/ There

THERE Are widgets being developed but it would be highly useful to developers these

, written to support keyboard interaction

RS: can you start writing a puse cases for these

MARC.. WANT TO MIGRATE question and test ov3r there.

Jw: users of Dragon doing drao0g and drop

SEARCHING THIS AND WILL BRING IT TO GROUP WHEN research is compkete

<mhakkinen> S/MARC/Mark

SEARCHING THIS AND WILL BRING IT TO GROUP WHEN research is complete

JW: Ballon exercises with static electricity. THEY USED ARIA LIVE REGIONS AND ARIA-describedby

Can move the ball on with arrow keys... used book be Flash but moving to SVG

You can do a lot of work but it's not very friendly across input type using currently the aria

We need to think carefully about how these types of inputs..

One direction of the research is molly modal using voice XML application, haptic or tactile graohs

Sions of ARIA

THÈRE ARE two approaches and the seconds could have implications for proposals

To the next version of WCAG.

No meeting next week

RESOLUTION: No WAI ARIA meeting next week

ARIA Working Group

23 Sep 2016

Attendees

Contents

TAG Review - ARIA

TAG Debrief

Triage

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output