Accessible Rich Internet Applications Working Group Teleconference

<joanie> agenda: this

<joanie> agenda: be done

<scribe> scribe: melanierichards

Incubating a Math ARIA and a Math AAM (joint with Math CG)

joanie: we are having a heavy liason relationship with getting math on web pages community group. I joined group as a member. We're talking about the need for math roles, states, and properties.
... we have talked in the past about, do we need parity with MathML?
... this will be a joint effort. if this pans out, they will be normative specifications. not committing to deliverables yet, just want to start working on it. making a couple new repos, Math-ARIA, Math-AAM.
... anyone who cares about Math ARIA can participate
... tentatively I'll be one of the editors, a co-chair of the group is another one. inviting anyone else who would like to be an editor

melanierichards: is the idea that implementors would be supporting MathML natively?

joanie: no, just generically need a way to expose expressions via roles
... in HTML AAM, some things have specific mappings, some say "use WAI-ARIA role". if the two hypothetical specs happen, then the 3rd logical step would be a MathML spec, but that does not require implementors to natively support MathML

jasonjgw: if there are people who plan to write expressive mathematical components, there could be an argument to use ARIA vs AOM. For role parity with what we already have in HTML...my main concern is that math could be used in interesting, idiomatic ways by authors. seems to require extensibility. still a question of how to increase semantics past what a set of roles would do
... not critical on proposal, just pointing out challenges

joanie: there's also an interest outside math: chemistry, music. we're really just incubating at this point

hhillen: if support for MathML has been so limited thus far, why support the roles?
... (why would the other browsers support the roles)

joanie: easy to say role="foo" and expose that in the accessibility APIs. whereas MathML requires a lot of layout and rendering and fonts and all this other stuff
... native MathML is a huge amount of work, how many people need it, for ex if everyone is using SVG anyway?
... right now all you can do right now is put aria-roledescription on something, AT can't use special way to navigate

melanierichards: +1 to what Joanie said about implementation resource difference between native MathML and math-related roles

New Issues since last check (19 July)

Charter: Status and changes requested by ACReps

joanie: we did get one comment with suggested changes, formal objection otherwise. W3C management working on that
... on Friday we did get another suggest changes, formal objection otherwise. Survey now closed, but we do have a second one
... for the AAM, it's not sufficient to say 75% of one implementation for the mappings for a given API. that's not enough. If there is more than one implementation for a platform, they want us to do the standard: 2 implementations
... questions/comments?

<clapierre> 2 implementations @ 75%?

michael: the management is sorting out the issues, in terms of what the commenters want, how they relate to reality of the work and W3C process. Working on a response, likely to take another week or two before sorted out. Anything that would lead to a substantial change, I would take back to the working group. Once we have an approached hooked up, we send to commenters, give them a week to reply, continue discussion

MichaelC: could be a few rounds back and forth, could be awhile til charter approved. We can keep doing business as usual, just can't publish before charter finalized

joanie: not clear if they want two implementations at 75% or at 100%
... need to discuss with them

New Issues since last check (19 July)

<joanie> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2018-07-19+

joanie: no new AccName issues. There are a few new ARIA issues
... we're just triaging new issues. We should probably deal with the open issues in 1.2. would people with authoring [missed] be okay with looking at these and commenting on them?

<clapierre> I will take my leave… thanks all excited about the new mathML and larger APA concept to help with Chemistry, Math, Music etc.

joanie: mattking volunteered
... [assigning to mattking]

<joanie> https://github.com/w3c/core-aam/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2018-07-19+

joanie: a few Core AAM issues

<joanie> https://github.com/w3c/core-aam/issues/16

<joanie> https://github.com/w3c/core-aam/issues/19

joanie: waiting for feedback on #16

melanierichards: will follow up

joanie: there is one about IA2 https://github.com/w3c/core-aam/issues/19 that might be helpful to get any implementor's feedback
... if you are an implementer, please comment
... triage is complete. questions/comments?

Issue 779

<joanie> https://github.com/w3c/aria/issues/779

<joanie> Consider moving normative, NON-mapping content from Core AAM to ARIA

<joanie> https://github.com/w3c/aria/pull/792

<joanie> Add an "Accessibility Tree" section describing inclusion and exclusion rules

<joanie> https://github.com/w3c/aria/pull/793

<joanie> Add a "Supporting Keyboard Navigation" section

joanie: these are open PRs for moving some of the content from Core AAM to ARIA
... we can either read these together, or go and comment on these ASAP independently. we need review, preference on doing this in the meeting?

<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/792.html#accessibility_tree

joanie: pretty much same content from Core AAM with minor tweaks

mattking: this looks really good to me. I see opportunities within the role descriptions to link to this section
... for example, in none or presentation role, there's places like that where we can link to the section you're adding

joanie: putting this feedback in a PR comment

mattking: I would say yes on this in terms of info architecture. I have the one question of if it's better before or after 8 or 9. Not a big deal though. Urge making this change that you have in the PR

<hhillen> +q

joanie: if memory serves, you mentioned it should go in section 7? But this isn't the same as that

mattking: agree
... the approach you've taken is the simple approach, and I like that

hhillen: [asked about divs cluttering up the accessibility tree]
... should there be a rule in here that a div without a role shouldn't be exposed?

joanie: no, [gave an example of other reasons to expose it]
... we would get pushback on this. if anything that belongs in HTML-AAM

mattking: I think I would raise this as a specific browser bug, rather than making the spec more demanding

joanie: there may be a bug in Mozilla's Bugzilla with a discussion about this...
... it's a valid point, but I don't think it belongs in ARIA spec

melanierichards: can comment today on PR

<joanie> https://github.com/w3c/aria/pull/792

<joanie> https://github.com/w3c/aria/pull/793

joanie: comment on whether this change should be merged into the spec or not, let's have that done before the next meeting and then I can prune Core AAM

this change = PR 792

<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/793.html#keyboard_navigation

mattking: section 2.3 is about managing focus...do we have to have both this section and section 2.3? They seem to talk about some of the same stuff
... There's also a part of section 8 that talks about tabindex.

joanie: this is not implementation and host languages
... it is implementation, but not host languages
... maybe I should try to move it under section 2.3

mattking: 2.3 is focus management, 8.3 is focus navigation, and now this other section
... I guess 8.3 is pretty nominal
... 2.3 almost seems redundant with some of the section in this proposal
... section 7.1 makes an assumption that's not actually stated here

joanie: I'm currently writing your comments into the pull request

mattking: even some simple conditional language that acknowledges 8.3 in host languages that provide tabindex, for example, at the beginning of that section

joanie: thanks, great feedback
... do you think this should be combined under 2.3?

mattking: I need to take a closer reading, but my first reaction is potentially yes.
... not sure whether to move this into section 2 or move 2.3

curtbellew: I do agree these could be put together into one section

MarkMcCarthy: would need a closer reading as well

curtbellew: tabindex is mentioned but not nearly as extensively in this new section, section 7

joanie: in my opinion, 792 is ready to merge pending feedback. for 793 I need to take a second pass.
... Thank you!

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

Present: Joanmarie_Diggs Mark_McCarthy MichaelC janina Stefan curtbellew Irfan_Ali hhillen melanierichards jemma Léonie jasonjgw matt_king clapierre Bryan_Garaventa
Regrets: Jon_Gunderson
Found Scribe: melanierichards
Inferring ScribeNick: melanierichards
Found Date: 02 Aug 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)