W3C

– DRAFT –
ARIA and Assistive Technologies Community Group

03 November 2022

Attendees

Present
jongund, Matt_King, michael_fairchild, s3ththompson, Sam_PAC
Regrets
-
Chair
Matt King
Scribe
s3ththompson

Meeting minutes

Candidate Review page testing

<Matt_King> Seth: Demonstrate the sandbox implementation of the Candidate Tests page

<Matt_King> This is the page that AT vendors will interact with when reviewing tests.

<Matt_King> Each venor rep has associateation with a specific AT.

<Matt_King> They have to be logged in.

<Matt_King> During screen share, walks through the experience of an AT dev rep who is reviewing a candidate test.

<Matt_King> They can raise issues to report problems with the test or provide feedback on the test.

<Matt_King> They can approve an entire test plan. That would change the review status.

<Matt_King> We would like community group members to reviewthe experience of people who are not AT vendors or test admins. That is, this is available for anyone to look at, we want to be sure the experience also works for the public.

<Matt_King> James: where are issues supposed to surface in the UI?

<Matt_King> Seth: They should show up in review status

<Matt_King> James: Is that not work8ing sandbox

<Matt_King> Seth: Need to check with eng

<Matt_King> Seth: We will be able to migrate existing feedback issues by editing their titles and labels.

<Matt_King> James: For opening an AT bug, what are we expecting?

<Matt_King> Seth: Still ambiguous. We could create issue in our repo, or could link to a different issue tracker for each AT.

<Matt_King> Discussion of how to track AT issues that are raised as a result of reviews.

<Matt_King> James: The issue title seems very wordy and hard to understand\

<Matt_King> Seth: We have previously discussed this.

<Matt_King> When we switch repos, I have a to-do to change the copy.

Feedback issue for Candidate Test Page: https://github.com/w3c/aria-at-app/issues/466

<Matt_King> James: feedback on test results heading

<Matt_King> Seth: Need to change heading copy for accordion?

<Matt_King> James: didn't now is a disclosure

<Matt_King> Seth: not sure there is an intent for it collapse

<Matt_King> so maybe not accordion

Alert Role Announcement

GitHub issue: https://github.com/w3c/aria-at/issues/840

Matt_King: so this issue is feedback from vispero on the alert role, which is one of the ones where they had the lowest score

Matt_King: they're not announcing the role alert when the alert is triggered

JoeHumbert: if it doesn't preface alert... what's the difference between an alert and an aria-live region with assertive?

Matt_King: right, i think that's the question. what's the difference for developers or users? why does this pattern exist if it doesn't vocalize anything different?

James Scholes: is the difference that alert is spoken even if you're not in the browser window?

Matt_King: there's nothing in ARIA about that

James Scholes: but i wonder if it is the case nevertheless... i can test that

James Scholes: vispero say that users have provided feedback that announcing alert is annoying

Matt_King: i think this change happened in 2022... Alyssa, you're a jaws user, right?

Matt_King: option 1) no change to test, we just acknowledge a difference in viewpoint and score would not change (we're not sure if this is viable, but they're not going to change the JAWS behavior); option 2) we could say that conveying the role is optional...

James Scholes: can we get a reading in the room?

JoeHumbert: would we have to change ARIA here? it says in the spec "an alert is a specialized version of role status..." if it doesn't need a specialized role, what's the point of having it at all?

Matt_King: there's also a few other things in there that no AT implements... when we authored this, the intent was that developers could create a more meaningful live event... the same way that windows has different sounds for different types of events. no AT is doing this, so in that sense, that aspect of alert has never been honored / addressed / implemented

JoeHumbert: one other suggestion: if users don't like it, give them a preference. in NVDA there are things that are announced as clickable. could be annoying, but that's why there's a preference

Matt_King: that is something we could discuss with Vispero...

James Scholes: i guess to rephrase, is there a possibility of an easy win here? if they have user feedback and there are no very strong opinions in the community group... maybe we can just amend? personally, i actually agree that this is a somewhat annoying announcement

Matt_King: one other perspective, as someone who has been an editor of the spec... we have an open issue in ARIA for aria regions and the need for an events API. at this case, i can say that the reason that ppl are using live alerts is that it is the only one that actually works... reliably, in all browsers. so if you want something announced reliably there's only one way.

Matt_King: so basically, there are lots of places that are using role alert (like basically all chat apps) where they are using role alert where they shouldn't be. if it was used more sparingly, and assertive and polite actually worked... then it could be an actually useful thing. because of that mitigating circumstance, i lean in the direction that James suggested, because the impact on users right now is actually pretty negative

jongund: it sounds like what you're saying is the ARIA spec is misleading at this point because the other roles have been around for a long time and they're not implemented

Matt_King: i'd like to return to this in the APG... we could create a live region pattern and example. we could pull a lot of different implementations onto a single page in the APG and then test that page and show the support levels. if we start testing that in ARIA-AT, then it would provide an impetus to actually fix this the right way

James Scholes: i like that approach. there are lots of issues and live regions are notoriously flakey. in the interest of getting this "win" under our belt, are we happy changing this to optional?

JoeHumbert: i'm always happy to defer to user feedback, so if they have that user feedback, let's use it. i do want to go back to the original thing: is it a slippery slope to change somehting that

JoeHumbert: *that's in the spec, just because one AT doesn't like it?

Matt_King: i'm worried about that too, but i think in this case, the way we avoid the slippery slope is by recognizing the ambiguity of the specification in this particular case

jongund: what's the difference between aria-live assertive and alert role?

Matt_King: only difference in spec is that the AT can play something like a system alert or otherwise react differently

Matt_King: thumbs up or thumbs down? proposed resolution: we change conveying the role alert to optional

michael_fairchild: +1

JoeHumbert: +1

<jongund> +1

Isabel Del Castillo SolĂ­s: +1

James Scholes: +1

Matt_King: okay, resolution passes, we'll make that change

Minutes manually created (not a transcript), formatted by scribe.perl version 196 (Thu Oct 27 17:06:44 2022 UTC).

Diagnostics

Maybe present: JoeHumbert

All speakers: JoeHumbert, jongund, Matt_King, michael_fairchild

Active on IRC: jongund, Matt_King, michael_fairchild, s3ththompson, Sam_PAC