ARIA and Assistive Technologies Community Group

07 April 2022


Alyssa_G, James, Matt_King, Rich_Noah, Sam
Matt King
Rich_Noah, s3ththompson

Meeting minutes

Recent and upcoming app changes

<Matt_King> Rich: shipped test plan version updater. Is now in prod as of March 30.

<Matt_King> no reported issues as of today.

<Matt_King> Current work underway is for capturing browser and AT versions.

<Matt_King> May 17 is target date for sandbox and reviews starting on 19th

<Matt_King> prod launch on May 23

<Matt_King> Didn't find a way to deliver in phases

<Matt_King> so it will all come at once

<Matt_King> mk: this is blocker for more testing. How can we continue testing in the meantime.

<Matt_King> Seth: perhaps we can find a way to collect the data offline and then backfill it.

Screen Reader Developer Engagement

Matt King: we're meeting with screen reader vendors to kick off the effort in the next 2 weeks (JAWS/Vispero, Apple) and we'll have the first 8 plans ready for the community group by April 26 and then ready for screen reader vendors in May

Matt_King: plan is to have the reports in a state where screen reader vendors can provide feedback with the tools that we have

Matt_King: since these are the least contentious 8 plans, we think we might be able to avoid handling a more complex review / reconciliation process

Screen Reader Dev Journey

Screen Reader Developer User Journey

<s3ththompson> https://github.com/w3c/aria-at-app/issues/409

Matt_King: I would like to make this week about the Developer User Journey and next week the Administrator User Journey

<s3ththompson> https://github.com/w3c/aria-at/wiki/User-Journeys-2022-(Draft)#user-persona-at-developer

s3ththompson: the link goes to the wiki page we have created for these journeys

s3ththompson: 3 scenarios listed and all related to reviewing candidate test plans

Matt_King: I am thinking that in terms of planning app changes I was imaging a Job to be Done.

s3ththompson: I believe we can massage these into that form

Matt_King: A job to be done sounds like "I want to indicate that I have reviewed it". I wonder if we want something similar to GH review.

james: this user journey implies they will file an issue and I don't believe that is the case

Matt_King: you need to know which ones at the test level and not at the test plan level

Matt_King: not at the assertion level

Matt_King: reviewing at a test would be reasonable

Matt_King: 1. Provide Approval 2. Request Changes 3. Have Questions - we want to make it easy to track these

s3ththompson: I agree and can share those with Isaac

Matt_King: we want to know where the bugs are raised and we would capture that information

Matt_King: The trigger to rerun automation should be the release of a new version

Matt_King: success is measured by how the SR developers change and react to it.

s3ththompson: what are the requirements around the process of reading these reports. The reports page is a better summary of information for someone coming new to the page to view it v. the runner.

Matt_King: I think the reports format is pretty good but I imagine something similar to the queue so they can see a list in their queue.

Matt_King: I think it will have to look something like a to-do list

s3ththompson: we have not talked about authentication, we would obviously want this to be a privileged role

Matt_King: we can assume all SR vendors will have GH accounts

Matt_King: these approvals are more of a project tracking as opposed to a formal approval. Would want to be careful on how we cast that.

Matt_King: there will be some political sensitivity as the project gains public credibility. how demanding we can be.

s3ththompson: I will revise this on the issue and I believe Isaac will be amenable to this. Then process to convert these to a set of requirements.

Matt_King: I think we might have to have a longer workshop.

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


Maybe present: s3ththompson