18:59:59 <RRSAgent> RRSAgent has joined #aria-at
19:00:04 <RRSAgent> logging to https://www.w3.org/2024/10/31-aria-at-irc
19:00:04 <Zakim> RRSAgent, make logs Public
19:00:05 <Zakim> please title this meeting ("meeting: ..."), Matt_King
19:00:15 <jugglinmike> jugglinmike has joined #aria-at
19:00:26 <Matt_King> MEETING: ARIA and Assistive Technologies Community Group
19:01:33 <jugglinmike> present+ jugglinmike
19:01:39 <Joe_Humbert> present+
19:01:44 <jugglinmike> present+ IsaDC
19:01:54 <jugglinmike> present+ Dean
19:02:00 <jugglinmike> present+ Matt_King
19:02:06 <jugglinmike> scribe+ jugglinmike
19:02:20 <jugglinmike> present+ James
19:02:46 <jugglinmike> topic: Review agenda and next meeting dates
19:04:00 <jugglinmike> Matt_King: Next Community Group Meeting: Wednesday November 6
19:04:06 <jugglinmike> Matt_King: Next AT Driver Subgroup meeting: Monday December 9
19:04:16 <jugglinmike> https://github.com/w3c/aria-at/wiki/October-31%2C-2024-Agenda
19:04:25 <Joe_Humbert> q+
19:04:41 <Joe_Humbert> I have a general question when time permits
19:05:01 <jugglinmike> Matt_King: Requests for changes to agenda?
19:05:47 <jugglinmike> IsaDC: I have a quick question: could we get the latest version of NVDA for the NVDA bot? It fixes some issues that we've had for disclosure
19:06:19 <jugglinmike> IsaDC: version 2024.4 (we have 2024.3 right now)
19:07:06 <jugglinmike> jugglinmike: Yes, that is generally a quick task, but we never know what we'll find with each never version. We'll prioritize this work next week
19:07:35 <jugglinmike> ack Joe_Humbert
19:07:57 <jugglinmike> Matt_King: Okay, then beyond that, we'll stick with the agenda as planned
19:08:29 <jugglinmike>  Topic: Current status
19:08:50 <jugglinmike> Matt_King: Now we have eight out of the ten plans that were in candidate review are up-to-date and current (it was seven last week)
19:09:03 <jugglinmike> Matt_King: Now, we just have "disclosure" and "navigation menu button"
19:09:41 <jugglinmike> Matt_King: Once that's done, all of the reports on the site will be in the new format. We're getting really close on that important milestone, and that will allow us to complete more of these conversations with AT Developers
19:09:53 <jugglinmike> Matt_King: Hopefully we'll be celebrating 10 out of 10 in the next couple weeks
19:09:56 <jugglinmike> Matt_King: And then beyond!
19:10:08 <jugglinmike> Matt_King: We are making progress in the conversations with both Apple and Vispero
19:10:25 <jugglinmike> Matt_King: I feel like we're going to be at the point where several of these plans are in the "recommended" phase, soon
19:11:04 <jugglinmike> topic: action menu button state priority question
19:11:10 <jugglinmike> github: https://github.com/w3c/aria-at/issues/1150
19:11:38 <jugglinmike> Matt_King: I almost hate to be raising this issue so late in the process
19:12:03 <jugglinmike> Matt_King: I'm asking whether or not communicating the state "collapsed" should be a priority one or priority two
19:12:26 <jugglinmike> Matt_King: I'm starting to feel that the state is only a "should" because you could still operate this button if you didn't know the menu was collapsed
19:13:15 <jugglinmike> Matt_King: For a long time, we said to only put the "expanded"/"collapsed" state on the button when it's expanded because it seemed unnecessary when collapsed
19:13:30 <jugglinmike> Matt_King: It's sort of like what Apple talks about with "pressed" and "not pressed"
19:14:10 <jugglinmike> Matt_King: There were a couple reasons why we shouldn't be inconsistent in that way. That we should always have "aria-expanded" and it should be up to the screen reader to determine whether it was conveyed
19:14:49 <jugglinmike> Matt_King: One of the issues had to do with touch. When you are using these things on a touch device, you can focus the expanded or collapsed menu button regardless of the menu's state. It's really helpful to know the state of the menu in that case, especially when the menu doesn't appear adjacent to the button
19:15:21 <jugglinmike> Matt_King: So the question I'm asking is about the "collapsed" state itself (not the state change)
19:15:33 <jugglinmike> Matt_King: I suppose this would also apply to when you're navigating to...
19:15:46 <jugglinmike> IsaDC: Also when you close the menu. I think it should stay
19:15:53 <Joe_Humbert> q+
19:16:03 <jugglinmike> James: I'm inclined to say that if aria-expanded was not conveyed when it was "False" on a button, I would be concerned
19:16:17 <jugglinmike> James: However, a menu button is different than a regular button
19:17:09 <jugglinmike> Matt_King: The disclosure is completely different. You wouldn't know that, otherwise. In this case, because it's a menu button which has its own roles...
19:17:23 <jugglinmike> Matt_King: With a "must" assertion, basically, people wouldn't be able to perceive the interface at all if the screen reader didn't perform it
19:17:55 <jugglinmike> Matt_King: I'm thinking about if a screen reader fails to convey a "Collapsed" state on a menu button, what is the impact on a screen reader's ability to use the menu button?
19:18:07 <jugglinmike> present+ Hadi
19:18:12 <jugglinmike> Hadi: They would miss it
19:18:30 <jugglinmike> Matt_King: Well, if it said "Actions menu button", you would still recognize the menu button--even though it didn't say "Collapsed"
19:18:46 <jugglinmike> IsaDC: We didn't have state before, when we first ran the test plan, it didn't assert state at all
19:19:15 <jugglinmike> James: Reading the definitions, my view is that it should be a "may". The "should" says that it is "likely to impede users". I don't think the lack of state information is likely to impede users
19:20:05 <jugglinmike> Hadi: sometimes the children are not adjacent to the parent. The menu must be exposed, but it might not be immediately after that button. I don't know that, so I have to explore back and forth. It might be a long distance to travel to those children. I'm more toward "must", but I'm open to "should." Not "may", though
19:20:20 <jugglinmike> Matt_King: The menu button is supposed to move focus into the menu when it is expanded
19:20:38 <jugglinmike> Matt_King: If the menu is collapsed and it just says "action menu button" and you press it, then the focus is supposed to go inside of the menu
19:20:53 <jugglinmike> Matt_King: Would that impede you from using the menu button effectively?
19:22:12 <jugglinmike> James: To clarify my previous comment: going solely on the assertion descriptions in isolation, I think this is a "may" because if a menu button is collapsed, it's true that focus does not necessarily move into the menu. The state being conveyed as "collapsed" does not necessarily help you avoid that situation
19:23:01 <jugglinmike> Matt_King: Since we're not asserting "expanded", if it didn't convey "Expanded", then you'd be in a bad place
19:23:25 <jugglinmike> James: Since we don't have a test for "Expanded" and any such test would be convoluted and contrived, I believe it should be a "may" for collapsed
19:23:44 <jugglinmike> s/"may"/"should"/
19:24:25 <jugglinmike> Hadi: These things have been developed to improve the experience for everyone, including screen reader users. I am tired of meeting the minimum requirement. This minimum requirement means more work for people to get something done
19:24:46 <jugglinmike> Hadi: I know we have some protocol to follow, but I don't mind pushing to make it a requirement
19:25:05 <jugglinmike> Matt_King: Remember that we're not talking about the web page developer; we're talking about the screen reader developer
19:25:24 <jugglinmike> Hadi: Exactly, if the web page author made the effort, the screen reader should respect that
19:26:17 <jugglinmike> Matt_King: The reason having the difference between "must" and "should" applied consistently throughout the test--the reason that is important is that new or not-so-well supported ARIA features become available, it's really important that a web developer be able to look at the report and say, "it is basically safe for me to use this"
19:26:44 <jugglinmike> Matt_King: If there are too many "must have" behaviors that most screen readers don't support, then we end up in a situation where it inhibits the use of ARIA
19:26:59 <jugglinmike> Matt_King: I'm thinking about the future and how people will use these reports then
19:27:05 <jugglinmike> Hadi: I still push for "must"
19:27:54 <jugglinmike> Matt_King: In certain tests, it is failing. It would still be counted as a "fail" even if the assertion was a "should". In that case, the score is still not 100%. If we changed it to a "may", they might not fix it. If it's a "should", they're still gonna fix it
19:28:02 <jugglinmike> IsaDC: JAWS is failing this right now. I was quite surprised to see that
19:28:04 <jugglinmike> Matt_King: Me too
19:28:30 <jugglinmike> Matt_King: That's one of the reasons why I raised this issue. I wanted to make sure we had it classified correctly
19:28:41 <jugglinmike> Matt_King: And in a consistent way
19:29:00 <jugglinmike> Matt_King: It sounds like Hadi and James are both comfortable with a "should"
19:29:36 <jugglinmike> IsaDC: I also vote for a "should" to kind of soften the blow a little without losing the "hit"
19:29:48 <jugglinmike> Matt_King: Yeah. I want to be able to explain each of these assertions.
19:30:14 <jugglinmike> Matt_King: I don't know if we should be writing the rationales down, e.g. why is this a "should" or why is this a "must" or why is this a "may"
19:30:58 <jugglinmike> Matt_King: In this case, because we are not testing for aria-expanded, it becomes particularly important that aria-collapsed is conveyed because if you're interacting with this with touch, it's really important that you know at least one of the states. Otherwise you would be severely impeded
19:31:10 <jugglinmike> Joe_Humbert: Does the button always convey that it is a menu, though?
19:31:25 <jugglinmike> Joe_Humbert: The APG says that it has to have a role of "button"
19:31:38 <jugglinmike> Joe_Humbert: If aria-haspopup is true, does that convey that it's a menu?
19:31:41 <jugglinmike> Matt_King: Always
19:31:58 <jugglinmike> James: the element's implicit role is button, but as soon as you add aria-haspopup, it changes the role
19:32:53 <jugglinmike> Matt_King: Originally, aria-haspopup was a binary. We made "true" equal to "menu" in the interest of backwards compatibility
19:33:11 <jugglinmike> James: We should assert that the role of "menu button" MUST be conveyed
19:33:49 <jugglinmike> Matt_King: I don't know if haspopup is mentioned in the references, but it needs to be in the tests for "role"
19:34:02 <jugglinmike> IsaDC: I remember adding it to the references file...
19:34:55 <jugglinmike> James: We're saying that the user "should" convey them to the user, but if it doesn't, it wouldn't prevent them from using the button
19:35:07 <jugglinmike> James: In that way, WCAG is very binary, where this is three-state
19:35:16 <jugglinmike> Matt_King: Yup, aria-haspopup is in the test
19:35:28 <jugglinmike> Joe_Humbert: That answers my question
19:35:39 <jugglinmike> Matt_King: I think we'll update all three test plans
19:35:47 <jugglinmike> Matt_King: I'll do a pull request for this
19:36:08 <jugglinmike> Matt_King: It won't affect any of the test plan results. No one will have to re-test anything
19:36:46 <jugglinmike> Matt_King: Thanks everybody for this discussion!
19:36:59 <jugglinmike> Topic: Testing Disclosure Navigation Menu
19:37:06 <jugglinmike> Matt_King: We have four conflicts right now
19:37:23 <jugglinmike> Matt_King: There are still three open issues about conflicts that I think might be resolved. I've listed those in the agenda
19:38:02 <jugglinmike> Matt_King: I think they're all tied to Dean's previous testing that we discarded
19:38:24 <jugglinmike> IsaDC: I'll take a look at those
19:38:40 <jugglinmike> Matt_King: Right now, I think we want to talk about the four conflicts about link activation with JAWS
19:39:54 <jugglinmike> Matt_King: Test 14. Hadi has much more verbose output. When I run this test, JAWS is extremely verbose. The focus moves to the heading, and JAWS reads information about the page as if the page had just completely reloaded. It counts the landmark regions and hotspots and stuff
19:40:01 <jugglinmike> Matt_King: I get that same result as Hadi
19:40:12 <jugglinmike> Matt_King: Mine's even more verbose than what Hadi wrote done
19:40:48 <jugglinmike> IsaDC: I believe I cut that out of the output because I considered all of that as part of hints, not as part of the result. Because it was breaking it down into giving a description that explains what's on the page
19:41:07 <jugglinmike> Matt_King: Actually, I think we should include all the output for any command. I don't know how we should edit down.
19:41:18 <jugglinmike> Matt_King: Think about the automation, for instance. It's going to capture all of the output
19:42:43 <jugglinmike> Matt_King: I think what JAWS is doing here is navigating to the heading, and then starts reading at the heading, and reads the rest of the page
19:42:54 <jugglinmike> Matt_King: I'm not sure if that's what Vispero wants to happen
19:43:16 <jugglinmike> Matt_King: Personally, I think it should only say "heading level 3 overview" first and then say the name of the landmark region
19:44:16 <jugglinmike> Matt_King: I think Hadi did the right thing here
19:45:10 <jugglinmike> IsaDC: I'll change my results to match Hadi's
19:45:23 <jugglinmike> Matt_King: Let's mark this as excess verbosity with moderate impact
19:45:29 <jugglinmike> Hadi: I marked it as severe
19:45:40 <jugglinmike> Matt_King: I don't know if Vispero would agree with that
19:46:05 <jugglinmike> Matt_King: I waste more of my life due to broken same-page links...
19:46:40 <jugglinmike> James: What are "smart glance highlights"?
19:47:00 <jugglinmike> Matt_King: JAWS analyzes the page and calls out things that seem visually pronounced
19:48:31 <Joe_Humbert> q+
19:53:27 <jugglinmike> ack Joe_Humbert
19:53:55 <jugglinmike> subtopic: Feedback: "Navigate backwards to an expanded disclosure button" (Disclosure Navigation Menu Example, Test 4, V24.10.10)
19:53:59 <jugglinmike> github: https://github.com/w3c/aria-at/issues/1148
19:54:31 <jugglinmike> Joe_Humbert: In the example, if the menu is open and the user is at the "navigate backwards from here" link--if I were to press shift+tab, should focus go to the last item in the menu or the last  button?
19:54:39 <jugglinmike> Matt_King: the last link in the menu
19:54:57 <jugglinmike> Joe_Humbert: I observed that the last menu item is selected, but the menu is not open
19:55:10 <jugglinmike> Joe_Humbert: This doesn't represent realistic behavior
19:55:14 <jugglinmike> Dean: I agree with that
19:55:41 <jugglinmike> Joe_Humbert: When you run the test setup, the button is shown as "active" but the menu is not visible
19:55:54 <jugglinmike> Matt_King: That's a problem
19:56:06 <jugglinmike> James: The test has nothing to do with a disclosure menu, it's for a disclosure button
19:56:24 <jugglinmike> Matt_King: But you could easily do that just by opening the menu and placing focus on the first link in the menu, and...
19:56:51 <jugglinmike> James: I think there was a problem with that approach. I'm not certain, though; this was a long time ago!
19:57:00 <jugglinmike> Matt_King: I'm kind of thinking that should be changed...
19:57:21 <jugglinmike> Joe_Humbert: The purpose of this test is to see what it announces when the focus moves backwards to an expanded disclosure button
19:57:42 <jugglinmike> Joe_Humbert: If it's a hack to get it to move consistently, that's fine by me. It just seemed odd
19:57:52 <jugglinmike> Matt_King: Which test number?
19:57:59 <jugglinmike> James: Test number 12
19:58:22 <jugglinmike> James: test number 12 overall, but it's the fourth test in the progress list
19:58:44 <jugglinmike> IsaDC: This could easily break the test itself, particularly with VoiceOver. That might be why it's not moving
19:58:56 <jugglinmike> Joe_Humbert: I understand. I can close this issue
19:59:32 <jugglinmike> James: I'm unclear why we didn't use a different script that exists for a situation like this
19:59:50 <jugglinmike> Joe_Humbert: So, do you want to keep this issue so you remember to revisit this?
20:00:12 <jugglinmike> James: I think it's okay because it's only hiding an element. If it were doing something advanced like intercepting shift+tab, that would be one thing
20:00:23 <jugglinmike> James: But I think what we have is fine
20:00:45 <jugglinmike> James: If others think it's a major problem, then we can absolutely change it
20:00:58 <jugglinmike> IsaDC: Thank you for explaining this, Joe_Humbert, because I didn't understand before
20:02:48 <jugglinmike> Matt_King: I hesitate to make more work. I'm a little concerned by this, though. I suppose we can try to push it through the way it is. If we get feedback from screen reader developers there, then we can address it at that time
20:05:16 <jugglinmike> Topic: Testing navigation menu button
20:05:28 <jugglinmike> github: https://github.com/w3c/aria-at/issues/1137
20:05:50 <jugglinmike> Matt_King: Is it okay if the role is conveyed in the hint?
20:06:03 <jugglinmike> Matt_King: I think it would be very difficult to tell Apple that the role isn't conveyed at all
20:06:23 <jugglinmike> James: To be honest, I would find a menu infuriating if it said "menu" all the time
20:06:28 <jugglinmike> IsaDC: It's just a "may" assertion
20:06:34 <jugglinmike> James: I'm glad for that!
20:06:56 <jugglinmike> James: If we were talking about a button, and VoiceOver just said the name and only said the word "button" in the hint, I think we'd all feel a bit different
20:07:10 <jugglinmike> IsaDC: But in this case, you know that you're in a menu and that you're moving through items
20:07:34 <jugglinmike> IsaDC: Do we pass it now? Because we failed it elsewhere when it was in a hint
20:07:42 <jugglinmike> IsaDC: Recognizing that it's a "may" assertion
20:07:54 <jugglinmike> Matt_King: If it was a "must" and it was in a hint, then there's a problem when the hint goes away
20:08:01 <jugglinmike> Matt_King: But they're on by default
20:08:16 <jugglinmike> James: If you have to wait for the hint to tell you something, then you'd never get anything done
20:08:31 <jugglinmike> IsaDC: For consistency, if we pass it here, we have to revert that other test and pass it there, as well
20:09:18 <jugglinmike> James: So in the activedescendent plan, the text is present in the hint, and we failed it. You're saying that if we passed it in this one, it wouldn't feel good because we'd have to go back to the other and change it (even though it's already been removed from the test queue)
20:09:29 <jugglinmike> Dean: We shouldn't do it the wrong way now just because we did it the wrong way before
20:09:49 <jugglinmike> Matt_King: Let's decide what's correct right now and then do whatever work that entails
20:10:48 <jugglinmike> James: I'm going on three things. The first is Apple's assertion of how many people turn off hints. Secondly, the fact that it's a MAY assertion, so it does not reduce the support level (in order to notice that this is even a fail, someone would have to look very closely at the report--it's  not a headline reduction in the support level).
20:11:04 <jugglinmike> James: I forget the third thing
20:12:28 <jugglinmike> s/I forget the third thing/Third, if we were saying that this is an important assertion and then it failed, we would feel much more strongly that this was an issue/
20:12:59 <jugglinmike> Matt_King: The fact that it appears in the hint, though. The words are there. There's some cognitive dissonance there. We just need consistency
20:13:42 <jugglinmike> Matt_King: When we record the output, we definitely need to record all the output no matter what. If we are going to say that hints cannot convey role or state or name or value (which we could), then there's questions about properties
20:14:05 <jugglinmike> Matt_King: I'm not sure whether hints should be allowed to convey certain properties
20:14:20 <jugglinmike> Jame: I think hints are hints and should not be required to use anything
20:14:28 <jugglinmike> s/Jame:/James:/
20:14:42 <jugglinmike> q
20:15:30 <jugglinmike> Matt_King: The thing for us to write down someplace, maybe the testing manual or in the glossary, is that hints are part of the output, but we won't process information in the hints to determine whether or not role, name, state, value, or properties are conveyed
20:15:50 <jugglinmike> James: I think that's fair. I disagree with Apple on many things. I fully agree on their stance, here, though.
20:16:22 <jugglinmike> James: They recognize that many people opt out of hints, and that among the 10-15% of users who have them enabled, that many of those people are developers or accessibility testers
20:16:32 <jugglinmike> James: And so that's why Apple views them as slightly redundant
20:17:07 <jugglinmike> Dean: I think we need to make a solid decision here. Either hint text or no hint text. If it's "no hint text", then turn off the feature and don't include it in the output
20:17:30 <jugglinmike> Dean: If Apple is saying that a low percentage of people use it, then we're creating problems by observing it
20:17:58 <jugglinmike> James: If we say that hints don't contribute to results but we include them in the AT responses, then we open ourselves to the kind of feedback that isn't helpful
20:18:27 <jugglinmike> James: With JAWS, hints are spoken immediately. With VoiceOver, there is a significant pause
20:18:39 <jugglinmike> Matt_King: Going back on our principle of testing out of the box...
20:18:54 <jugglinmike> Dean: In that case, we should do the opposite of what I described earlier
20:19:04 <jugglinmike> Matt_King: I'm trying to have my cake and eat it, too!
20:19:39 <jugglinmike> Matt_King: VoiceOver and JAWS gets hints wrong sometimes, and I would like to be able to call that out
20:20:04 <jugglinmike> Dean: It doesn't make sense to say that "We use out-of-the-box settings" when 80% of users don't use out-of-the-box settings
20:20:31 <jugglinmike> Dean: If 15% of people hear additional information, that's fine, but we need to decide what's mandatory in the output that everyone is hearing
20:21:11 <jugglinmike> Matt_King: The problem is that we don't have those numbers. Vispero tells us that beyond changing the speech rate, most users use out-of-the-box settings. Apple is telling us that most people turn off hints. I believe that's true on iOS
20:21:29 <jugglinmike> Matt_King: I would say that 100% of developers have the hints on.
20:21:51 <jugglinmike> Dean: If they're getting their 10-15% based on developers, then that's not relevant
20:22:05 <jugglinmike> Dean: My vote is that everyone turns off hints when testing with VoiceOver
20:22:15 <jugglinmike> Matt_King: We don't want different rules for different screen readers
20:22:47 <jugglinmike> James: I felt that James Craig was quite firm in his assertion that hints should be discarded
20:23:12 <jugglinmike> James: I know many advanced users that make many customizations yet they still have the hints turned on
20:23:36 <jugglinmike> Matt_King: The first thing I do with VoiceOver is turn down the verbosity
20:24:40 <jugglinmike> Matt_King: I'm feeling stuck between what Dean is saying and things that we've agreed to earlier. This concept of testing out-of-the-box is pretty important
20:25:58 <jugglinmike> James: If we write a test plan for aria-description, and a VoiceOver user navigates to the control that has aria-description, and VoiceOver says "more content available" without reading more. Would you, at that point, say the failure has occurred, or would you say the user should open the item and find the description, and assign a verdict based on what the screen reader says then
20:26:10 <jugglinmike> Matt_King: We haven't discussed how to interpret responses in that case
20:28:47 <jugglinmike> IsaDC: What should we do?
20:29:15 <jugglinmike> Matt_King: Dean believes it's unacceptable to include hints in the output but then ignore that information when assigning verdicts
20:29:26 <jugglinmike> Dean: That will complicate things far too much in my opinion
20:32:46 <jugglinmike> Matt_King: I guess we need to review the pros and cons. Maybe this is a slightly more complicated decision than we would like it to be
20:34:19 <jugglinmike> James: The question is, are we going to be able to find more information that makes this decision easier?
20:34:37 <jugglinmike> James: The only things I can think is: speaking to more community group members and speaking to Apple
20:35:06 <jugglinmike> Matt_King: I would like to create a table of pros and cons and presenting that to others. I think getting alignment on that information is important
20:35:48 <jugglinmike> Matt_King: Even though this is an optional assertion right here, it's going to come up in a "must" or "should" at some point. That's why I don't want to decide based on the fact that the issue right now is for a "may" assertion
20:36:40 <jugglinmike> Matt_King: I don't think we need to make a decision based on the suggestion of one screen reader developer. I want some consensus
20:36:47 <jugglinmike> Matt_King: I'll try to help us map out a decision path
20:36:58 <jugglinmike> IsaDC: So we won't move anything right now
20:37:22 <jugglinmike> Zakim, end the meeting
20:37:22 <Zakim> As of this point the attendees have been jugglinmike, Joe_Humbert, IsaDC, Dean, Matt_King, James, Hadi
20:37:25 <Zakim> RRSAgent, please draft minutes
20:37:27 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-aria-at-minutes.html Zakim
20:37:34 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
20:37:34 <Zakim> Zakim has left #aria-at
20:37:35 <jugglinmike> RRSAgent, leave
20:37:35 <RRSAgent> I see no action items