W3C

– DRAFT –
ARIA and Assistive Technologies Community Group Weekly Teleconference

03 July 2024

Attendees

Present
howard-e, IsaDC, James_Scholes, jugglinmike
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

Review agenda and next meeting dates

Matt_King: No AT Driver meeting on Monday July 8

Matt_King: No meeting Thursday July 11

Matt_King: Next community group meeting: Wednesday, July 17

Matt_King: How about we plan the next automation subgroup meeting for Monday July 22, and we plan to reserve a portion of this meeting on Wednesday July 17 for anything pressing?

jugglinmike: Sounds good to me!

Matt_King: I'll create a one-off meeting and ask you to move it from the "draft" state

Current status

Matt_King: 6 recommended plans by September 30.

Matt_King: We'd like 4 more by December 31.

Matt_King: We had a good meeting with Vispero where they recognized some bugs that we discovered here

Testing of Color Viewer Slider

IsaDC: Joe will be testing tomorrow

Matt_King: Great! Then we'll just need Hadi's input

Disclosure plan draft

Matt_King: IsaDC has a pull request with a draft of this test plan

Matt_King: Input is welcome, though we don't have folks in attendance today who might normally take a look

Matt_King: I will take a look at this soon

w3c/aria-at#1083

Matt_King: Public comment encouraged!

IsaDC: Could we remove test 23, "Activate a link in a dropdown"?

IsaDC: that's really testing the link...

Matt_King: In this case, that link is working like a same-page link, right? Isn't it moving focus?

Matt_King: I think this is a useful test

Matt_King: In the link test, we don't actually test what happens after you execute a link, do we?

IsaDC: No because it opens in a new window

IsaDC: I was thinking about removing this test because I saw it first as just activating the link. But it does have an effect after the focus moves...

Matt_King: Yeah, it does. Focus gets set on a heading in this particular example

Matt_King: It seems like a useful test. The fact that its in this particular test plan is, I guess, interesting. But the fact that it is moving focus within the same page is an implementation of this example

Matt_King: I don't know if that reflects or does not reflect what actually happens in real-world websites

IsaDC: In that case, I suppose it's fine to keep it

Matt_King: I'm more curious about test #22, "Dismiss a dropdown"

Matt_King: The normal behavior of a disclosure is that it is not something that can be dismissed. You just toggle it

Matt_King: It feels to me like we should stick to the basics, here.

Matt_King: Normally, disclosures don't close with "escape", but some people were insisting on that behavior because visually, it looks like a menu

Matt_King: But because it is a disclosure, as a screen reader user, I would never think to use "escape"

Matt_King: ...because I'm not going to interpret these things as menus

James_Scholes: My expectations kind of depend. When we recommend disclosures for navigation menus, we do suggest to clients that they collapse on "escape"

James_Scholes: sort of a convenience to people who are not screen reader users since they don't have something like "shift+B" to back out

James_Scholes: But realistically, I don't know how many keyboard users really expect that

Matt_King: The functionality is there, and we can test it, technically

James_Scholes: The reason why I think the test is useful is that some screen reader and browser combinations struggle with the state change under some circumstances (depending on the order of operations)

Matt_King: I am actually observing exactly that kind of problem with JAWS (in similar situations, not necessarily this specific situation)

Matt_King: That's a valid reason to test it

Matt_King: This set of tests looks pretty good!

Matt_King: With all these states and all these directions, you end up with a lot of tests. I'll give this a deeper dive before Tuesday, but overall, I think this is the right set of tests

Matt_King: It's certainly better than the previous set of 44 tests

IsaDC: Thank you!

How reports express assertion verdicts

Matt_King: Documentation of proposed changes: w3c/aria-at#1050 (comment)

Matt_King: This started as a result of feedback from Vispero

Matt_King: They were concerned about our expression of assertion verdicts for an optional behavior--using the terms "pass" and "fail"

Matt_King: I wrote a definition of "assertion verdict" for the glossary

Matt_King: It reads: "A judgement of whether an assistive technology exhibits the expected behavior defined by an assertion when a test that includes the assertion is performed.

IsaDC: That sounds good to me

James_Scholes: Me, too

jugglinmike: Technically speaking, these verdicts will still be encoded uniformly as boolean values

jugglinmike: I'm just wondering if it will be okay for us, internally, to speak generally in terms of "passing" and "failing" verdicts, and mostly relegating this more nuanced terminology to the reports (which are the public view of the test results)

Matt_King: That sounds right to me

Matt_King: I'm really happy to have a decision here; this is great

Matt_King: I'm going to document this in the wiki, and if there isn't an issue on the ARIA-AT App side about updating the reports (I don't think there is), then I will raise one

howard-e: Confirmed that there is no issue, yet

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Maybe present: Matt_King

All speakers: howard-e, IsaDC, James_Scholes, jugglinmike, Matt_King

Active on IRC: howard-e, jugglinmike