Next meeting: April 4, 2023

[zcorpan]

In #4 we agreed to have a cadence of once per month, but the time for the kickoff didn't work going forward for everybody. So we should find a new time. About a month from now is the week of April 3.

Please indicate your availability here (3pm CET through 10pm CET, April 3 through April 6):
https://doodle.com/meeting/participate/id/eZ8jVLEb

[cookiecrook]

Optionals who I recall expressed interest from ARIA WG: @scottaohara @MelSumner @spectranaut @cyns @aleventhal @jnurthen

[zcorpan]

Right now, two people have filled in the doodle which resulted in a single possible time: Thursday April 6, 5pm CET.

Is this time OK or should we try to find a new time the week after?

[spectranaut]

I believe, as that will be after the time change in Europe, that will be 8am California time. That should work for me, at least!

[cookiecrook]

Right now, two people have filled in the doodle which resulted in a single possible time: Thursday April 6, 5pm CET.

I don't understand. You and I were the first to fill it out, and we had 14 overlapping time possibilities.

[cookiecrook]

There is now one time slot with 5 out of 7 respondents: @zcorpan, @gsnedders, @scottaohara, @jnurthen, @cookiecrook.

• Tue, Apr 4 at 9AM Pacific

I could also add 8AM or 9 AM Pacific on Monday Apr 3rd, which would include @chrishtr, but drop @jnurthen.

I did not see @spectranaut's response in the Doodle.

[chrishtr]

Update: it turns out April 4 would actually work better for me after all than April 3.

[zcorpan]

@cookiecrook I meant 2 not including myself. :)

With @chrishtr 's update (assuming "yes" for both times below) we now have:

• Tue, Apr 4 at 9AM Pacific / 6pm CET: 6 yes (but not including @spectranaut )
• Tue, Apr 4 at 12PM Pacific / 9pm CET: 5 yes, 2 if need be (@gsnedders and @cookiecrook )

[chrishtr]

Sorry I didn't even see the second page of results. I can do any time 8am Pacific or later on Tuesday. 12pm is good.

[zcorpan]

I've created an invite for April 4, 12PM Pacific. Repeating first Tuesday every month.

[zcorpan]

Present: @cookiecrook @chrishtr @cyns @spectranaut @jnurthen @zcorpan @gsnedders @boazsender

graphics-aria role mappings needed as precursor to svg-aam role mappings

Jcraig: Chromium returns the literal role, WebKit returns the superclass role. My guess is that the spec authors (@AmeliaBR) will define Chromium's behavior as correct when a computedrole column is added in w3c/graphics-aam#7.
Val: I worry that the implementation details may cause unnecessary churn for implementations.
Jcraig: Will need to be done for DPUB-ARIA anyway, b/c platform role mapping changes that apply to platform, we need to do that in webkit to support those changes. This is 3 extra roles, seems OK.
Val: these 3 being graphics-aria?
jcraig: yeah
Jcraig: But for some roles, the superclass role may be sufficient. Open to the ARIA WG and extension spec group.
Jcraig: Maybe we should have this discussion with Amelia BR
Chris: Testdriver status? Is it working?
Jcraig: yeah.
Crhis: so we have some automated tests now, and previously we have none?

Track progress

Chris: how are we tracking work we’ve done?
Jcraig: issue #3 kinda is that. Gecko maybe shouldn’t be checked yet since we’re waiting for geckodriver update, but bug has been fixed. (Going over status about tests)
Chris: so for example fallback role tests, links to an issue. Subjective what that should cover?
Jcraig: roles.html is simple, the returned role is same as input role. Html-aam is a separate issue. Things that require contextual containment in aria like grid, list, are tested in separate files.
Chris: So no RFC?
Simon: No, not needed for standardized webdriver features to be added to testdriver.js.
Chris: Landed last year?
Jcraig: discussed in BTT in 2019, landed maybe last year
Boaz: Geckodriver status?
Simon: Implemented, waiting for new release.
Jcraig: We’ve found some impl differences already. Passing the tests is out of scope.
Chris: Clarify scope, run but not passing.
Chris: So no further RFCs or things needed to be standardized? Only new tests?
Jcraig: Some of that are Agenda+
Chris: you’ve written some of the tests James, do you plan to write them all?
Jcraig: haha no, help appreciated. I want to get the basics done. There are a bunch of other contributors in ARIA that might not be comfortable writing python or even JS but simple markup-based tests in testdriver may be easier.
Jcraig: Going back to the PR, there are two main functions in aria-utils.js. Example listitem needs to be in a list, use verifyRoleBySelector(). Data-testname is optional but needed when there’d otherwise be duplicate test names (default to expected role name). Roles.html uses assignAndVerifyRolesByNames(). Roles.html has all roles in ARIA but some are commented out if they’re tested in another file.
Boaz: cool! People at Bocoup may have time in May/June to write tests.
Jcraig: I plan to present to the ARIA group. Open to ideas. Documentation ideas from someone who didn’t write the code.
Boaz: should I open an issue about documentation?
Jcraig: yes please

Discuss potential for additional webdriver accessibility properties beyond computedlabel and computedrole

Jcraig: venue for standardizing and discuss ideas? Parent/children, properties. Example , are in conflict. “Computed aria required” or accessibilityElement.required. Suggest WICG AOM, open to other ideas. There’s also a WHATWG TestUtils spec.
Simon: TestUtils gc() isn’t webdriver, is JS API but not enabled for users by default.
Boaz: Are these needed for P1 or P2 tests?
Jcraig: no. In scoring criteria, P1 and P2 are testable with what we have now. Unscored investigations are new spec extensions. See comment in issue #3.
Cyns: I’d be happy to bring this into WICG AOM. Wondering what other people think.
James: Wondering if people in AOM are interested in this.
Cyns: good point.
Chris: are there other AOM things going on right now?
Cyns: Shadow DOM. Salesforce and Igalia are driving.
Jcraig: I can find the explainer. https://wicg.github.io/aom/explainer.html
Jcraig: “Full introspection of the accessibility tree”. Part of original AOM plan.
Cyns: Different people might show up depending on teh agenda in AOM.
Simon: AOM seems OK, but also keep BTT in the loop (file an issue).
Cyns: sounds good
Jcraig: Objections?
Cyns: Put on the agenda for AOM group?
Jcraig: Discussed last time. They’re OK with it. I spoke with @alice about it yesterday, too
Val: Are you talking about working towards parent/child?
Jcraig: Different possibilities depending on the AOM discussion. Obvious ideas are computedparent and computedchildren through webdriver, or a new AccessibleNode object. Has to be async so webdriver is a good choice.
Val: I’d be interested in that discussion.
Chris: Is it not well defined in the spec?
Val: difference between what we’re defining here and … example ignored div, when is it ignored. Not straightforward in the spec.
Jcraig: there is no spec for what accessible parent node means in the browser internals. Gecko builds the internal accessibility tree by starting with the DOM and adds stuff from the render tree, WebKit is the opposite. Chromium is somewhere in between. E.g. div with a link in it, and has overflow: scroll. In webkit there’s a mock object in between. But it’s an implementation detail.
Chris: so AOM should define what accessible parent means?
Jcraig: depends on outcome of the discussion.
Cyns: an experimental interface will allow us to expose that complexity. There are differences.
Jcraig: I think the implementations will probably already match on ~90%…
Cyns: The tests can help us understand where the gaps are.
Simon: webdriver extension or DOM extension?
Jcraig: we’ve talked about it in AOM. Don’t know. Maybe we need a kickoff meeting. AOM time is afternoon Pacific, som it may be inconvenient for people in Europe. Alice is in Australia.
Jcraig: there was an experimental API in Chrome a while back, was pulled out probably, but even so this one would be different... readonly among other things.
Cyns: behind a flag still.
Sam: When we spoke about this before we discussed doing it in WebDriver so that it can be done cross-origin. It’s useful to be able to check that there’s a video control which is a button. Variety of things where we want to go into Shadow DOM as well. UI decisions. But a11y reasons to test those.
Cyns: Combine with Shadow DOM effort maybe.
Jcraig: Sam, are you suggesting the discussion be owned by BTT?
Sam: AOM seems sensible. But worthwhile soliciting feedback from BTT.
Chris: I think it’s a good idea to define what these things mean, but plan to only expose through webdriver. Agree to only define testing surface.
Jcraig: Yes agreed. This is testing API, not new web API.

Actions

• Post the notes (Simon)
• Create Documentation/accessibility test writing guide for wpt (Boaz, Jcraig)
• AOM issue 197 (Jcraig)
• AOM agenda+ (Cyns)
• Test writing with ARIA group (Jcraig/Jnurthen/Val)
• Later: File issue with BTT
• Address and close existing Agenda+ issues (Jcraig)
• File issue Track new API for WPT accessibility testing beyond role and label #26 to track spec extensions (Jcraig)

[zcorpan]

Next meeting: #25