Accessible Rich Internet Applications Working Group Teleconference -- 10 Nov 2017

<jeanne> scribe: jeanne

Agenda bashing

Joanie: We are going to do prep for the 11:00 meeting with Web Platform WG
... we may do some follow-up at lunch.

Prep for Web Components

Joanie: ARIA WG is going to provide the semantics for AOM
... including role and attribute parity
... the work being done in ARIA should support the work in Web Components

<joanie> Web Components Meeting Prep

<joanie> * The ARIA Working Group is going to provide the semantics needed by AOM, starting with HTML role and attribute parity which is the focus for 1.2 (and possibly beyond).

<joanie> * The work being done in AOM should support the needs of Web Components, and should be able to do it more cleanly (i.e. without "sprouting" and leaking attributes)

<joanie> * Our conclusion at the present time is that Web Components should use AOM and ARIA will ensure that AOM has what it needs to support that path.

Jason: One of the issues discussed at last year's meeting was an ID reference of an element outside a shadow tree to an object inside one.

<joanie> * Let's all keep talking.

Jason: does that mean we don't have that problem anymore?
... my collagues at my company did a paper about it a year ago and didn't encounter any problems.

Francois: ARIA is descriptive and helps clarify role. There are components, like support for selection inside a component, that are not supported in ARIA. Web Components will be used more and more to create new components. They need to be accessible but they can not be expressed in ARIA

Matt: I'm not familiar with that, but it seems that the accessibleNode features in AOM would be able to address most of what you need.
... if you were going to use a Rich Text Editor in HTML, there are still some elements that cannot be expressed in HTML. BUt I am not familiar with t hat events you are discribing.

Francois: You can have nodes in Canvas and they can do the same as virtual Nodes, but they are not in the DOM. But there is a way to control selction in these nodes. Selection would be undefined.
... ARIA is describing the states, but there is handshaking that is not described.

Matt: Are they being propogated into the Accessibility Tree now?

Michael: The problem exists now but the AOM team is working on it. ARIA just defines semantics, AOM is the language that does what you are looking for.
... a problem we constantly deal with in accessibility is that new components are constantly being updated. That was the reason ArIA was created and is the reason we need to be able to update more often so that as componetns in the wild gain traction, they are included in ARIA.

Francois: There is more work to be done

Michael: That is why we want to have a discussion on requirements, and how ew can make ARIA easier to update.

Joanie: As a screenreader developer, I don't always get the information I need. In theory, they should be addressed, and we need to insure it is in the core AAM.
... Also in the case of Web Components which use Shadow DOM, ARIA cannot support that, only AOM can.

Jason: I don't have a good example

Joanie: aria-activedescendent is a good example
... web components depends on AOM, and AOM depends on ARIA, and it has to be done this way because of Shdow DOM.

<jsajka> scribe: janina

Michael: we should set up a github issues to help coordination

<sajka> scribe: janinawe need to be sure to coord well with aom, we're perhps a bit more formal than they

<scribe> scribe: jeanne

<joanie> Graphics roles: I don't expect to have any changes to this text, unless significant problems arise when trying to get the mappings sorted out.

<joanie> Next steps:

<joanie> - get the Graphics-AAM reviewed & updated as necessary

<joanie> - republish Graphics-AAM and SVG-AAM as updated WD or CR

<joanie> - develop a full, updated test suite for SVG-AAM using the new mappings

<joanie> - get implementations running the test suite!

<joanie> - decide if any new edits are required, otherwise everything to CR

Joanie: Amelia has been editor of the graphics AAM and SVG AAm
... there are 3 roles in the Graphics-AAM

Michael: I think we should be tracking the fate of the documents. We can decide who is working on what, but we should track them.
... Bogdan is taking over the SVG AAM

<MichaelC> ACTION: Joanie to follow up with Bogdan on how SVG intends to proceed on SVG-AAM wrt to Graphics-ARIA and Graphics-AAM

<trackbot> Created ACTION-2140 - Follow up with bogdan on how svg intends to proceed on svg-aam wrt to graphics-aria and graphics-aam [on Joanmarie Diggs - due 2017-11-17].

Michael: Amelia can do editing tasks, but doesn't have time to do much more
... I will contact people to get ARIA-mappings

<MichaelC> ACTION: joanie to obtain mappings and generate test results for graphics-aam

<trackbot> Created ACTION-2141 - Obtain mappings and generate test results for graphics-aam [on Joanmarie Diggs - due 2017-11-17].

<AmeliaBR> 👍

<AmeliaBR> Thanks everyone, glad to see these specs starting to move forward again!

Jason: When SVG Accessibility TF was operating, their role was to develop ARIA specific content for graphics, particularly data visualizations.
... the DIAGRAM Center is looking at data visualizations outside of W3C, and have gathered organizations to address it.

Joanie: looking at Graphics AAM has three roles
... graphics-document, graphics-object, graphics-symbol
... Why can't it go to REC sooner?

Michael: If we do it on a timeline that is favorable to them, I assume they will have no problems with that.

Joanie: I will provide pull requests. There are adjustments needed which hopefully will be accepted by Amelia, and then we can talk to Liam.

Michael: I will look at a charter and see if they have milestones about it.
... Their charter says they want to take AAM to REC in February. They think they are a month behind. They may want to do a working draft soon. The Feb timeline for CR might be delayed by the same amount

Joanie: We don't want them to go to CR without corrected mapping

<AmeliaBR> If there are commitments by implementers, it shouldn't be hard to get it to REC. The test suite for Graphics-AAM itself will be very simple.

<AmeliaBR> SVG-AAM test suite will be more complex, and likely need more work from implementers & possibly spec revisions.

Joanie: MathML AAM and MathML role pairing. There is no document that says how to implement MathML mappings.
... Daniel has an issue on MathML that he has opened in Github.

Jason: I want to see consistent MathML implemented accross platforms. It is important to my organization and to publishing.
... there has been some discussion of how to deliver MathML to platforms that doesn't support MathML. Some people have suggested that SVG be used to make it accessible. I have received strong protests when it has beeen raised.
... what if the DOM order doesn't match the logical order of the mathematical expression that accessibility will not be provided the way we want it.

Michael: There is a active group working on Math outside of W3C, so we will need to coordinate with them.

Joanie: There is an incubation group or a community group.

<joanie> https://w3c.github.io/mathonwebpages/

Jason: Server side rendering issue that some MathJAX developers wrote where they said that they would move to a server side rendering which would then be delivered to the client. There would be no accessibility of that, and there would be a request for ARIA roles to handle it.
... it is highly presentational, and it kis not clear how ARIA would handle it.
... the DIAGRAM Center and Benetech are working on it.

Glen: The best experience that has been had with JAWS has been with Wikipedia, with MathML with SVG fallback. Except where Firefox which renders MathML, other platforms are delivered SVG. It would be horrible with aria roles.

<AmeliaBR> me/ to joanie: no one's writing anything currently. Fred was working on it last year.

Michael: I don't know how MathML is rendered through the screenreader, but there is precedent in how it is renderd on desktop rendering.

Glen: Mostly it is plucking out the HTML and then navigated as a tree of elements so you can navigate it as so eventually you are reading a small part of the expression.
... Microsoft is using their Math module. You can navigate it lineraly, but it is impossible to edit.

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

Glen: the three options on the desktop. There is prior art on the desktop that could be studied.

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

Glen: preserving MathML would be a priority

Irfan: There is a math layer with Design Signs that works for NVDA. With @@ set, you can get good accessibility.

Joanie: It's not as simple as giving it to a math player.

Jason: I'm in agreement with Glen about this.
... there are implementations across several platforms. Joanie thinks there would be value in standards. I don't think there is value in addressing it with ARIA.
... there is a group within DIAGRAM Center that is writing authoring practices.
... there are sample test pages

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

Matt: There was somebody who requested who requseted MathML parity within ARIA. I heard the concerns from Jason and Glen that disagree with doing it in ARIA. I don't see where it falls within the scope of ARIA. Maybe I'm not understanding.

Michael: My view is that any accessiblity API mapping is within our scope, but that doesn't mean we should do it.
... I want to see us doing any AAM that makes sense to us.

Joanie: [reading issue]
... his company is involved, so he is a stakeholder.

Alice: I don't disagree, but I'm wondering if this is a case for modular roles, where we could create the standard without being included in core

Joanie: I'm having a hard time visualizing how it could occur.

Alice: It could be a Github repo iwth the text and tests.

Michael: I agree, I would like to see us increase modularization

Francois: The CSS WG has been working with modules for a long time, and I think it has enabled us to move more quickly to ReC that are stable, and enable us to work more on things that are less stable.
... have multiple specs, and lets people support the specs they want to.

Alice: If it is not feasible for 1.2, then it can be in a separtae module until it is mature and then you can roll it into the spec whenever it is mature.

Joanie: 1.2 is more of a phase than a document

Micheal: We agree that we should do modularlization, although we would like to do it differently than CSS. We should talk through the process issue, but not to do it now. The general suggestion is welcome.

ALice: [reviews the AOM prep for the Web Components meeting] I agree.

Joanie: Do we need to discuss Setters / two-way ARIA

Alice: we can probably get along for a while just in AOM. I want it eventually to be consistent, but we don't have to address it urgently.
... we can experiment with two-way ARIA for a while and then we can collaborate on it. If it is not a burning issue for you, I don't see that we have to address it immediately.
... as we continue the process of seeing what AOM/ above looks like, we can discuss it.

Joanie: I am trying to get an idea of what things we want to put in the rechartering.

Michael: It takes about 6 months to get rechartered. The charter expires in July 2018. There is more pressure from the Advisory Committee to not do incubation in working groups, so exploratory work is going to raise eyebrows.
... there is more emphasis on timelines, which is good, but resources are not always in our control.
... I would like to keep general AAM work in the charter
... but normative ARIA modules need to be specific with version numbers and milestones
... the charter lasts for 3 years. We want to think about what we want to accomplish in the next three years, so we don't need to recharter early to work on a particular topic.

Matt: There was a discussion about what ARIA 2.0 might bring and control patterns. It seems like we were getting mired last year in the debate over the big issues that need to addressed. Fundamental action and usability issues in the accessible experience.

Michael: I forgot to say is that some explicit coordination with AOM should be called out in the charter, even though it isn't a deliverable.
... parity issues are not incubation.
... we have lost a lot of time to incubating, and I want to find a way to incubate outside the owrking group, either by task forces or incubation groups.

Janina: HTML seems to be pretty stable. There are still issues with media. Now that publishing has merged into W3C, the HTML issue is opened up. There are issues that were not included in the MAUR.
... publishing opens that again. We may not want to approach full parity, but should say that we are addressing that moving target

Jason: Making complex visualizations accessible. Interactive simulations. The potential need for ARIA extension in support of complex applications. There isn't a positive case being established for these, but they are being discussed. HTML parity isn't going to touch these issues.
... keyboard shortcuts and functions have been in preliminary discussion.
... we need a forum to discuss proposals outside the main charter deliverables.

<Zakim> MichaelC, you wanted to talk incubation coordination and to say versioned HTML parity and to say runway of features with scheduled updates

Jason: if there is a way to do that within the W3C process, there is a good reason to do that.

Michael: In response to Janina's comment about the HTML version, we would tackle that later.
... in response to Jason, we have a whole runway of features that we want to see in the spec.
... Web Platform has a goal to complete a spec once a year, and then publish with whatever features are complete.
... Alice asked how to stay in the loop on incubation. With AOM, we want to establish tools for an incubation mechanism for ARIA. I don't have specifics now.

Joanie: Jason reminds me that we haven't decided what to do with Drag and Drop. We deprecated it what we have.

Matt: aria-dropeffect and aria-grab are deprecated.

Joanie: If you deprecate it, you need to replace it.
... I want consensus on Drag-and_Drop in ArIA versions

Janina: Proposal: leave it alone until HTML picks it up again.

Matt: I think the problem is that we don't know what we want to do yet. I'm not very active in the DIAGRAM Center/Benetech group, but I am keeping an eye on their work. They are doing incubation-type work.

Jason: I am the chair of that group and they are in the use case development stage.
... they happen in educational simulation concepts.
... gap analysis and author guidance
... if the outcome is the suggestions for ARIA, then that should be taken up.
... if we have the incubation mechanism in place then that will handle it.

Janina: what language are these complex interactions for? I still think that we should not do this outside the main markup standards. I don't see how it fits.

Jason: SVG or WebGL.
... I am avoiding saying that there are gaps to be filled, but there may be.

Janina: I understand that publishing is setting up incubation group as part of their merger in W3C, and we could address it there. It isn't a deliverable in a 3-year charter. It is in the "may prove necessary" bucket

Joanie: WebGL will be made accessible through AOM. We don't know what it will be, but when AOM tells us what it be, then we will address it.

Jason: It's another case of Canvas accessiblity

Dominic: There is some Canvas accessibility, but there isnt a way today. We plan to take it up in AOM>

Janina: There is @@ working on that environment, then we will be talking about it, but I don't see a time schedule that would make it into a 3 year charter.

Joanie: Sanity check on the posted list?

Matt: I assume we don't need to put small items in the charter. THat there is a genreal, "clean up point releases".

Michael: If we have them before the charter that is helpful.

<joanie> MUST DO:

<joanie> * HTML version 5.X role (and property) parity - "1.2 cycle" (and beyond?)

<joanie> * Setters / two-way ARIA - "1.3 cycle"

<joanie> * Ongoing feature addition to support AOM

<joanie> * (Charter needs to include statement of coordination with groups like AOM)

<joanie> * Miscellaneous feature tweaks and additions (e.g. aria-expanded on menuitem)

<joanie> MAY STILL HAVE TO DO:

<joanie> * Graphics + Graphics AAM (i.e. if milestones slip)

<joanie> WANT TO DO:

<joanie> * MathML AAM

<joanie> DUNNO YET:

<joanie> * MathML role and property parity

<joanie> * Drag and Drop (we deprecated what we have) - leave it alone until HTML picks it back up?

<Zakim> joanie, you wanted to discuss agenda/process/wrap up

Next session is in B&C.

Joint meeting with Web Platform WG re Web Components

<jamesn> what channel?

<Roy> #webplat

<MichaelC> https://www.w3.org/2017/11/10-webplat-minutes.html#item02

<janina> scribe: janina

jd: Believe grx and grx.aam could be ready for CR after Nov 30

mc: Pub preparation is easy, but we need to dispose of any open comments

jd: Oops, wrong specs ... rewind!

bogdan: Not identified svg blockers, but svg.aam blocked by grx.aam
... We can work on testable statements meanwhile
... We have editor for svg.aam; Ian Pouncey

mc: Quickest we could move grx.aam would e early December.
... However, suggest another WD of your spec before CR

jd: Also looked at svg.aam and understand your grx.aam dependency
... I've implemented on Webkit for Safari and ATK/AT-SPI2
... Does Apple actually call their API AX-API?

DS: Not sure

jd: Phps we made that up
... I'll review svg.aam before asking Michael to move ...

mc: Reiterate another WD before CR.

<MichaelC> ACTION: joanie to plan a WD of graphics-aam with goal to go to CR à la https://w3c.github.io/spec-releases/milestones/?cr=2018-01-11

<trackbot> Created ACTION-2142 - Plan a wd of graphics-aam with goal to go to cr à la https://w3c.github.io/spec-releases/milestones/?cr=2018-01-11 [on Joanmarie Diggs - due 2017-11-17].

jd: If we're too slow with grx, what's the impact?

bogdan: Not serious--will still make progress

jd: Unsure if subroles are correct in mappings--minor details, but we want it correct

mc: Don't know how/why. Should discuss with SVG-A11y TF

bogdan: would not expect most would subclass img

<scribe> scribe: janina

jd: Looking at the taxonomy ... Need to clarify
... Other questions?
... We should discuss creating the testable statements
... With SVG

Authoring Practices Task Force

<BogdanBrinza> https://github.com/w3c/aria/pull/664

[setup interruption ...]

mk: Long time goal of APG was canonical best practices for ARIA
... Milestones Wiki ...
... Current milestone is release of APG-1.1
... Previously we've been WD
...

e hope to release with ARIA-1.1 TR

<jamesn> https://github.com/w3c/aria-practices/milestones

jd: Noting Dec 7 Rec not likely, likely later Dec or early Jan

mk: Our goal was a functional example for every widget role
... Our original scope was bigger

<jamesn> https://github.com/w3c/aria-practices/milestone/1

mk: We have 74 open issues
... So, we had to adjust our expectations
...

Remainder items in future releases until all of ARI

A covered

. We're organizing record of our decisions using github projects

<jamesn> https://github.com/w3c/aria-practices/projects

mk: Makes it easier to track history of particular items

<jamesn> https://github.com/w3c/aria-practices/projects/5

mk: looking at menus and menubars -- reviewing open items some 35 or so

. Large scope and lots of work
. We're looking for consensus on our guidance
. We have minimum of 3 people in T

F working on any given item before putting out for wider review

. Implicit of publishing a Note is that the WG agrees
. Only way to really review this stuff is to actually use it
. So wondering how to do for wider WG
. Suggest at least 2-3 weeks ahead of actually moving to a CfC
. Looking for review suggestions on this work for this release

sf:

A general question ...

sf: Concern of nonalignment of conformance and bp

mk: We have 3, actually
... We understand 1 item can be fixed in next WD, and 2 others vixed n validator
... Difference of how aria can be used when implementations in browsers are all correct vs
... the real world of hacks and plyfills
... We want to guide for devs

jn: We're actually dual purpose -- help AT work better
... Not quite an off the shelf lib

sf: is role=none still an issue?

mk: Not an error, provides warning

sf: Hmmm, not in spec
... Looked into fallbacks and found issues of not well ordered

jn: Browsers you'd need, don't support fallback

sf: Wrote article, but don't recall the details off hand

jn: Once we have Ed draft of 1.2, we can go for these fixes

jd: that's my understanding
... Understand we can start 1.2 drafts now?

mc: Absolutely

jd: I will work with Michael to make this happen

sf: No big rush

<joanie> action joanie to work with Michael on getting FPWD versions of Core AAM and ARIA out

<trackbot> Created ACTION-2143 - Work with michael on getting fpwd versions of core aam and aria out [on Joanmarie Diggs - due 2017-11-17].

bg: Q about apg for at and browser devs vs authors
... Does it actually say that anywhere?

mk: read.me

<jamesn> http://w3c.github.io/aria-practices/#browser_and_AT_support

mk: If it doesn't work, we're highlighting a bug

bg: That's not clear as to who the audience actually is

mk: Maybe we can be more clear, i.e. enhance examples or code?

bg: Should be clear that the purpose of the archive make these examples work more widely--across the board

jn: Phps a link to this statement in the doc
... We'll discuss

Evan: Looking at the doc, looks opposite ...

mk: Need to fix
... vast majority of patterns do work

jn: Statement is directed examples, so we should move the statement there
... Verbiage otherwise is general guidance

mc: We always announce particular concerns when we announce the publication

sf: Suggesting pointer to workaround bug ...
... A resource where someone can respond with a workaround
... Could help surface and resolve issues

jn: Hoping some consultancy will come up with a "can i use" review

sf: Noting anyone can file a bug against the doc

[discussion of how to support bug/improvement tracking]

mk: Will a couple weeks pre CfC work for review?

sf: Want to note we're using this in our TPG work extensively. Thanks, and keep it up!

mk: Good to hear! Very motivating

jd: Noting the project management tool, looks interesting

jn: Not fully accessible

mk: Pretty accessible

jn: A few issues that are hard to do

Personalization

<MichaelC> Personalization Semantics Editors´ Draft

mc: Introducing the draft spec which came from COGA-TF
... Originally conceived as an ARI

A module

mc: Lisa and Charles are Co-Facilitators
... Hope to get 1.0 out soon
... TF reviewinguse cases that p13n properties resolve
... I have suggested we conceive of this as a vocab
... Should make it possible to add these in a tech neutral way
... Currently Appendix showing how to implement in ml independent manner, e.g. rdfa, etc
... Therefore the question of same name plus a prefix?
... have been using 'coga-' prefix, to clarify these came from COGA and not yet official ARIA
... Could be ARIA- .or. some special a la doc- from publishing

cl: Don't want to stay with a coga- prefix because these are applicable well beyond cognivite and learning disabilities

<Roy> https://www.w3.org/2002/09/wbs/101569/prefix/

cl: So is aria- possible? Not?

sf: Wondering whether these are to be replicated in ARIA, microdata, rdfa, etc., etc.

mc: In q for same issue, would like input
... Is this useful vocab, module struct? What's the view

jn: Definitely not ARIA module
... Expect AT built on this, so far broader

mk: +1 to jn

<jamesn> we cannot see the results of the survey

mk: noting the clash already with 'status'
... Best to get this carved out into its own branding would be smarter

jw: aria has well defined role, but not so here
... e.g. to hide ui componants could be misused even with good intentions
... Wondering what the spec will say about potential uses of this tech?

cl: COGA-TF wanted to explore these, doesn't mean these are all implemented in 1.0
... So, hearing not aria-

<clapierre> https://www.w3.org/2002/09/wbs/101569/prefix/results

jw: noting vfocab not connecting to aapis, but some other use yet unclear
... another argument to not align with other aria modules
... See it as a distinct project

<Zakim> MichaelC, you wanted to ask if we even want attributes

mc: Do we even want these as attributes?

jw: Recalling the ssml discussion yesterday, microdata was raised there
... Also noted uses could be wider than aapis
... this seems similar
... would like to see good proposal that aligns this with ssml approach

cl: Understand john foliot took these up with schema.org, and agreed not appropriate there

jw: also noting privacy concerns when these are communicated along with a login

mc: Following the discussion seems attribs may not be best, phps microdata
... If we still call it vocab, but focus microdata? Easier to get uptake?

<Zakim> MichaelC, you wanted to say emphasizing microdata means less implementation fragmentation

cl: If we're to change course, now's the time to do it
... Can't say which ml best, but we want it easy to implement so it will be more likely get implemented

mc: We should do an eval
... Believe microdata was intended to replace rdfa

cl: still prefix?

mc: Microdata has its own approach

mk: would like to see a thoughtful overview of options

<MichaelC> HTML Microdata

mk: real work here is design
... once well designed, how to code won't matter

jw: Noting microdata still wd

cl: Only other concern was timeline, but hard to say if we don't know the technology to be used

mc: We should still consider timeline we want

cl: Asking when WG would need something from the TF?

jd: Do we need specificity for the Chartering? It won't be in this Charter?

mc: In our Charter

jd: Do we expect this work finished by end of current Charter? Really?
... So, we recharter with this and get more time

mc: We'll be epxected to set a timeline and stick to it, and we'll need to expect why not finished--and should be able to explain that
... fast or slow not the issue, meeting the advertised timeline is the issue

jd: I always under-estimate !!
... We should provide feedback on proposed milestones for this
... Asking for realistic milestones soon

mc: part of meeting milestones is managing dependencies. we need to factor those appropriately
... also, this is all very new. we need to plan for due dillegence to get imjplementation

cl: definitely on the diagram/Benetech plans, phps our web site
... if works on our site, could push to Bookshare

jd: Also want regular TF checkins on ARIA telecons

<joanie> action joanie to contact task force facilitators regarding once-a-month check-ins during Thursday's Working Group call

<trackbot> Created ACTION-2144 - Contact task force facilitators regarding once-a-month check-ins during thursday's working group call [on Joanmarie Diggs - due 2017-11-18].

CSS A11y TF

mc: Expect CSS-AAM and a CSS BP
... Some kind of explanation doc explaining nav problem(s)

<MichaelC> CSS A11Y TF

<MichaelC> CSS A11Y TF projects

<MichaelC> https://github.com/w3c/css-a11y/projects/4

mc: Also notes spec reviews

jw: SFB A11y discussed nav
... proposal for 8-way spatial nav
... Seems there's need for a wide discussion of nav
... Unclear how CSS AAM helps

<jasonjgw> Janina: suggests that the Research Questions Task force would be a suitable venue for the navigation discussion.

<jasonjgw> She outlines the role of the Task Force in investigating specific topics.

<jasonjgw> There are opportunities to participate.

jd: Could probably come up with CSS to map with my Orca dev hat on, and will after some other business is cleared

mc: We may not need to own the AAM
... Suspect we have ARIA in TF with expectation that ARIA might craft the solution--but unclear what/if this happens. Certainly not today

Accessible Rich Internet Applications Working Group Teleconference

10 Nov 2017

Attendees

Contents

Agenda bashing

Prep for Web Components

Joint meeting with Web Platform WG re Web Components

Authoring Practices Task Force

Personalization

CSS A11y TF

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output