ARIA Face to Face Day 3 -- 03 May 2018

<bgaraventa1979> dialed in using the same number, please let me know if a different meeting code is needed

<joanie> https://www.w3.org/2018/03/draft-aria-charter

<joanie> https://www.w3.org/WAI/ARIA/workflow

<joanie> https://www.w3.org/WAI/ARIA/roadmap

ARIA Charter

<mck> scribe: matt_king

<mck> JD: describing roadmap and charter

<joanie> Achieve Parity with Native Host Language Semantics

<mck> highlighting that scope of roadmap is bigging than scope of charter.

<joanie> Add new roles to achieve parity with HTML elements (Target: ARIA 1.2)

<joanie> Add new states and properties to achieve parity with HTML attributes (Target: ARIA 1.3)

<mck> Summarizing html parity goals

<joanie> Evaluate the need for parity with additional host languages and implement as appropriate (Target: Ongoing)

<joanie> Provide Support for the Accessibility Object Model

<mck> Summarize proposed support for AOM.

<joanie> Add ARIA property string reflection on Element (Target: ARIA 1.2)

<joanie> Other items to be determined as work on AOM progresses (Target: Ongoing)

<mck> Making AOM possible also helps ARIA goal of automation for testing.

<mck> JG: how far out is AOM phase 4 where it can answer question "is feature x implemented?"

<mck> jd: maybe not as far out as thought during tpac.

<joanie> Develop and Maintain Additional ARIA Features for Authors and End Users

<joanie> Add and/or modify ARIA features based on feedback from authors (Target: Ongoing)

<joanie> Map new and modified features to platform accessibility APIs (Target: Ongoing)

<joanie> Update platform accessibility API mappings specifications maintained by this Working Group when the platform APIs change (Target: Ongoing)

<joanie> Write authoring guidance for new and modified features (Target: Ongoing)

<joanie> Collaborate with user agent implementors and assistive technology developers to maximize interoperability (Target: Ongoing)

<joanie> Specific items that the Working Group plans to accomplish, which will entail a non-trivial amount of effort include:

<joanie> Develop an alternative solution to replace the now-deprecated ARIA drag-and-drop features (Target: 1.4)

<joanie> Create means to set ARIA attribute values through platform accessibility APIs (Target: 2.0)

<mck> all: discussion of drag and drop. At this time there are no critical dependencies.

<joanie> Ensure Consistency in Platform Accessibility API Mappings

<mck> jd: remember that we can modify the roadmap as needed; different from charter in that way.

<joanie> Review Accessibility API Mapping specifications produced by other Working Groups (Target: Ongoing)

<joanie> Create and maintain solutions for automated accessibility API-based testing of the exposure of roles, states, and properties of elements in native host languages (Target: Ongoing)

<mck> jg: a key part of that is Dominic and Alex setting things up on the browser side.

<mck> part of this is making it easier for them to understand mapping needs.

<mck> jg: We're going to demo some of the ATTA work later today.

<joanie> Identify host languages for which there are no associated Accessibility API Mappings specification and collaborate with the Working Group that maintains that language to determine what solution, if any, is appropriate (Target: Ongoing)

<mck> mk: what about control patterns?

<mck> jd: any other things to include in roadmap?

<mck> mk: Adding control patterns that enable programtic declaration of interaction models supported by an interactive widget.

<mck> jd: please provide any charter-review relevant changes by tuesday.

<joanie> https://www.w3.org/WAI/ARIA/workflow

<mck> jd: Summarize work flow process.

<mck> mk: Discuss nature of APG content needed; important to have everything.

<mck> jd: Directing people to appropriate doc for the type of reader; need to direct authors from spec to APG.

<mck> mc: respec has announced canIUse integration.

<mck> jd: might be good way to link to test results from spec

<joanie> https://www.w3.org/2018/03/draft-aria-charter

<mck> JD: Summarize charter

<joanie> out of scope: Technologies for which corresponding Accessibility API Mappings do not need to be defined.

<mck> jd: Definition of success criteria.

<joanie> For ARIA specifications, implementability and interoperability will be demonstrated by having at least two independent implementations of each of feature defined in that specification.

<joanie> For every platform with mappings in an Accessibility API Mapping specification, at least one implementation of 75% of the mappings to that platform will demonstrate implementability on that platform. Multiple implementations of each platform are not required because some platforms have only one implementation. For features that are not platform-specific, passing test results in at least two different

<joanie> implementations will be documented to demonstrate implementability

<mck> mk: is the 75

<mck> percent of the new or total?

<mck> mc: in WCAG we explicitly state we are testing new. should do same in aria.

<mck> jd: Adding "new features" language.

<mck> jd: Date of charter is roughly august. Want at least a year for 1.2.

<mck> Want dates te same for all the specs.

<mck> Don't want more than 2 years.

<mck> Proposing date of dec 2019.

<mck> mc: looking at milestone planning tool. from last call to rec is roughly 3 months.

<mck> 1.5 year cadence seems like about right.

<mck> jd and jn: like nov 2019.

<mck> TPAC 2019 dates not yet set.

<mck> jd: like just before tpac for PR.

<mck> jn: OK with CR at tpac.

<mck> mc: want to go to rec before holidays.

<mck> that means pr in oct.

<mck> jd: pr and rec in 4q?

<mck> mc: if pr is at start of qquarter.

<mck> mc: would rather have rec be in quarter following the pr quarter.

<mck> Decision: 1.2 rec in q4 2019.

<mck> jd: can we do 1.3 in q4 2020?

<mck> we will start work on pwd for 1.3 when 1.2 goes to cr.

<mck> jn: I am good with that.

<mck> jd: I'm focusing on core AAM and testing. I need something off my plate. I am looking for an editor for accname.

<mck> bg: I could take it over.

<mck> bg: would like to have Aaron on board too.

<mck> jd: ideally we would have to editors.

<mck> two editors

<mck> bg: I need a request from the chairs so I can take it to my employer.

<mck> jd: great first pull request would be adding yourself as an editor.

<mck> all: discussion of waht is needed to get accname 1.1 out the door and then set dates on accname 1.2.

<mck> jn: we will be ready to go with accname 1.1 very soon.

<mck> jn: should we put accname 1.2 in sync with the other specs in q419?

<mck> mc: yes

<mck> jd: dpub AAM module 1.1; not planning new roles at this time. Shall it be a 1 year cycle as well?

<mck> mc and jn: yes

<mck> mc: should if OK in dpub in svg groups, my guess is yes.

<mck> mc: may need to refine before reviewing with AC

<mck> jd: grapics module?

<mck> mc: Propose aligning with the rest for now.

<mck> jd: for the timeline in the charter, we need first pwd dates for everything.

<mck> jn: for future fpwd's, like for 1.3, we should be able to do it at the same time as CR for 1.2 but for sure by the time of rec.

<mck> mc: yes, feasible.

<mck> jd: If the svg working group is ever disolved and there are no future versions, we still need the graphics module so all the svg in the wild can be accessible.

<mck> mc: Timeline minimally needs fpwd and rec

<mck> jn: fpwd's will be in jan following the recs.

<mck> mc: fpwd of 1.2 will not be in charter b/c we will get it done before the new charter is published.

<mck> goal to publish fpwd by the time new charter goes to AC for review.

<mck> jd: by when then?

<mck> mc: mid june.

https://rawgit.com/w3c/aria/charter/charter/index.html

<joanie> https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_file-label-inline-hidden-elements

<joanie> mck: https://github.com/w3c/aria/issues/721 and https://github.com/w3c/aria/issues/722

https://www.w3.org/WAI/ARIA/track/issues/542

Need to move to either the CSS Task Force or to AccName

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