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

<joanie> agenda: this

<joanie> agenda: be done

<scribe> scribe: janina

TPAC Debrief

<joanie> https://www.w3.org/2017/11/09-aria-minutes.html

jd: Any hallways news relevant for us?

<joanie> https://www.w3.org/2017/11/10-aria-minutes.html

jd: Any reactions to share re TPAC? Especially if not minuted?

<jongund> having trouble getting into webex

<jongund> doesn't like the password

irfan: Self intro ...
... Notes met us during TPAC
... Had conversation about a11y support in Firefox Quantum
... Unclear there's a11y support in Quantum
... Any knowledge much appreciated
... Personally coming up to speed on a11y. New to the field

jd: Welcome ...

mk: Re Quantum -- Their new multiprocess architecture performs poorly with Windows, just not performant
... Screen readers will need to accomodate
... For now multiprocess can be disabled and may work better

jn: Not any longer
... Advice is to stay with FF52 for now
... Believe there's sr work, but also ff work to clean it all up
... Notes that Chrome works just fine

jg: Single entry for msaa+ia2 should be great
... Notes each have their own role properties, each of msaa and ia2
... If it is important, it needs to be in the testable statement

jd: Notes jg is sole source of info on msaa+ia2

jg: Notes he's relying on student labor

AccName Status and Proposal

jd: Not sure of all the history ... but
... Have doubts of the split of accname
... acname-aam isn't a single spec
... reviews aam -- m means mapping, the platform independent name calculation
... Notes the provided table is already in core
... Is an issue because of testable statements and exit criteria
... In core we're at least one implementation per api at least 70% complete
... Example: There will be only one UA implementing UIA, Edge
... So different exit criteria between core spec and aam spec
... Proposal ...

<joanie> 1. Remove the mapping-related content from "AccName AAM" on the grounds

<joanie> that it's redundant.

<joanie> 2. Remove the "AAM" from the AccName spec's title because AAMs are for

<joanie> platform-specific mappings.

<joanie> 3. Add any mapping-related content that is in the current AccName AAM

<joanie> but not covered in the Core AAM to the FPWD of Core AAM 1.2,

<joanie> and use that as the starting point to sanity-check and fix those

<joanie> mappings.

[end proposal]

jd: Notes there's nothing preventing us from starting ARIA-1.2 even as we finish 1.1
... We won't be failing to test by removing per proposal above
... Should improve our precision
... Testing will also help us be clearer

mc: Michael suggests we need to absorb this for awhile ...
... Can we decide now, or do we need to think about it

jg: Seems a good idea

[crickets]

mc: If I understand, proposal is to move mappings to core-aam

mk: Still wondering why yet another spec. Never understood the split
... Only the tables are the actual mappings, possibly should be all that's split

mc: Believe there were some reasons, but unsure the recollection
... Believe because it bogged down spec work
... Implementation became too much of the conversation
... Then we started getting tangled with html as well as aria mappings
... We wanted to keep the distinction clear
... That way both core and html mappings could reference without duplication
... Now wondering whether it actually worked out like that
... Believe the algo still has html and aria in it

mk: Unclear when this becomes a critical priority
... Want to look at what's in the core-aam spec that isn't a mapping table and ask myself why it's there
... Concerned about two docs getting out of sync, and having too many places to look
... Would be very happy with tables only in aams
... Wondering whether accname could simply go away?
... Concerned about fragmentation

mc: We had issues in 1.0 with the nonmapping portion

mk: Deserves a second look, but don't want to decide now

jd: Patches welcome! Would love to trim down non mapping portion of accname-aam
... Believe we need decision on accname in order to get it to CR soon. It continues to slip
... What tests and exit criteria depends on this
... Believe we need to decide soon

mc: If we make no changes we need to test both algo and mappings, unless already tested

jd: So, will send proposal to list
... Would we need CfC?

mk: Don't we want to finish accname and then worry about the clean slate?

jd: Processing relations in Windows ATTA if we don't, else will be hand testing
... It will be a bigger testing job to not make this change
... If we change, could get our two implementations from Gecko and WebKitGtk

mc: In the proposal, we keep stuff and just move it around. Shouldn't be an issue with the Director
... If changes, we can explain and should still be OK. Process shouldn't be the blocker

Next Steps

jd: Have a list of minor issues ... Loose discussion for now from planning perspective ...

[discussion of calendar to year's end]

jd: Item, grx and grx-aam

mk: Would like to have tweaks needed by the validator in place before repo split

mc: Could be editor's draft of the doc destined to be the first wd of ARIA-1.2
... Looking at several repo issues, but understand Matt's point

jg: Noting many embedded pattern rules in the specs
... Wondering about extracting rules for testing tools
... Phps recommended rules for APG?

jd: Please follow up with github issue and list post so we don't lose this

jg: Not enough people know what we're doing

<mck> /me got to go to another meeting

jg: Discussed APG at recent conference presentation and people wished they'd known about it months ago

jd: Anything else for now? ...

Accessible Rich Internet Applications Working Group Teleconference

16 Nov 2017

Attendees

Contents

TPAC Debrief

AccName Status and Proposal

Next Steps

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output