Test Feedback: Redefine assertions for "Activate a link in a dropdown" (Disclosure Navigation Menu Example, Test 14, V24.10.10)

[mcking65]

It is not clear what behaviors to expect when a same page link is activated.

Same page links can refer to any of:

• An empty element
• An element containing a text node
• An element with an easily conveyed name and role, e.g., a heading.
• An element containing multiple semantic elements

Currently, this test asserts that activating the link will cause screen readers to convey information about a heading that appears at the link target. However, the heading is not the link target. The target is a div that contains the heading and content that follows the heading.

Ultimately, users need to know:

1. The link was activated.
2. The reading cursor or focus is moved.
3. Sufficient information about the new location.

Unknown: Does focus, i.e., document.activeElement, always move to a link target?

Assertions should be based on expected behaviors that:

1. Are applicable to any same page link.
2. Are applicable to any screen reader.
3. Support the user needs.

Options:

1. A single simple assertion, e.g., "The new location is conveyed"
2. A set of assertions that require information about a specific element to be conveyed based on some consensus logic. Example: Convey first non-empty element at or immediately following the target.

Test Setup

• Test File: test-65-activateLinkDropdown-jaws.collected.html
• Report Page: Link
• AT: JAWS (Version 2024.2406.121)
• Browser: Chrome (Version 130)

[css-meeting-bot]

The ARIA-AT Community Group just discussed Issue 1194 - Same-page link assertions.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 1194 - Same-page link assertions
<jugglinmike> github: https://github.com//issues/1194
<jugglinmike> Matt_King: This came up during the testing of the disclosure navigation menu
<jugglinmike> Matt_King: The thing that we're testing is the behavior that occurs when you activate a same-page link
<jugglinmike> Matt_King: In the disclosure navigation menu example, you activate a link in the navigation menu to the overview page, and the example script loads the content of the overview page which includes a heading that says "overview"
<jugglinmike> Matt_King: What happens is your screen reader reading cursor is placed at that point in the DOM (it travels from the link overview to this place on the page in the heading)
<jugglinmike> Matt_King: The href on that link is pointing to an ID and the ID is on a DIV, and that DIV includes that heading as well as some additional content
<jugglinmike> Matt_King: We have written assertions for that test, and the assertions are currently saying that it should announce the heading role, the heading level, and the heading text
<jugglinmike> Matt_King: but we don't have a basis for those assertions in the standards!
<jugglinmike> Matt_King: Because the heading is just the first thing in the div
<jugglinmike> Matt_King: This came up in our meetings with Vispero because their behavior in this particular case was not great, and they fixed two bugs. It prompted a discussion about what "SHOULD" the behavior be?
<jugglinmike> Matt_King: The challenge with same-page links is that they could be pointing to an empty span, a container with a lot of content, a semantic element like a heading, or a element with no semantics and just a text done
<jugglinmike> s/done/node/
<jugglinmike> Matt_King: We're kind of in a tough position here because if we want to have expected behaviors that work for any same-page link...
<jugglinmike> James_Scholes: I'm not sure that we do want that
<jugglinmike> Matt_King: Great point. I wrote about this in the issue
<jugglinmike> Matt_King: If we're going to define expected behaviors for any specific example. Say we were going to test a bunch of different examples--we would need some kind of approach to saying what the expected behaviors for each of them. What is the basis for saying "these are the things that should be spoken in this specific case?"
<jugglinmike> James_Scholes: It sounds like what we're implying is the behavior of the common-case even though we're only testing one pair of roles
<jugglinmike> Matt_King: When we test combo box, we will use the exact same principals for every single combo box
<jugglinmike> Matt_King: In essence, in all these cases, if you go back--from our tests, we're going to be able to derive general principals about expected behaviors. This is kind of test-driven standards development, in a sense
<jugglinmike> James_Scholes: I agree. But there are always cases that are going to be more easily matched than others
<jugglinmike> James_Scholes: [gives an example of such a case]
<jugglinmike> James_Scholes: I think you're right that the current assertions don't have any basis in the standards
<jugglinmike> James_Scholes: I think we should assert that it reads the role of region and the name and leave it at that
<jugglinmike> Matt_King: If our test is based on a principal that only applies in one specific case, then how does that help if you are testing a different same-page link?
<jugglinmike> James_Scholes: The role and the name should be relevant regardless
<jugglinmike> James_Scholes: I think those expectations hold across use-cases
<jugglinmike> Matt_King: It sounds like you're kind of deriving an algorithm
<jugglinmike> James_Scholes: Sure
<jugglinmike> Matt_King: I suggested that we could have a generic expectation or a specific expectation
<jugglinmike> Matt_King: A generic expectation would be an assertion along the lines of "the new location is conveyed". We have the user needs (they need to know that they activated the link and where the link took them to). If we had a generic assertion like that, and we left it up to every individual screen reader to decide how to convey that
<jugglinmike> Matt_King: Or we could have a specific assertion based on some kind of logic--that's what you're talking about James_Scholes. The only challenge there is that we need to come up with some logic that we can get all screen readers to agree to
<jugglinmike> James_Scholes: I don't think the logic I've proposed would be controversial
<jugglinmike> Matt_King: I'm not saying that it's controversial, but I'm concerned it may be an issue for folks that need to consider all the edge cases
<jugglinmike> James_Scholes: We're not testing all the edge cases, though
<jugglinmike> Matt_King: But we need to be prepared to write such tests for interoperability purposes
<jugglinmike> James_Scholes: I don't think it's appropriate for a screen reader to approach a project like ours and say, "because this test has been written in such a way that it may fail X% of tests, we don't think it's valid"
<jugglinmike> Matt_King: This project, as I've seen it, has been taking the logic that is expressly stated (generally speaking) in other specs--and that we're just pulling it together and trying to make it explicit. Things about how you respond to state change, focus change, etc...
<jugglinmike> Matt_King: Things we've done with, eg. radio, is all based on what's in the accessibility tree and why it's there
<jugglinmike> James_Scholes: so is what we're discussing right now
<jugglinmike> Matt_King: I agree
<jugglinmike> Matt_King: I would agree that it's pretty much impossible to cover all possible implementations. At a minimum, we're trying to cover all examples in APG and trying to be systematic about it
<jugglinmike> Matt_King: Though we have talked about writing separate tests which are more atomic
<jugglinmike> James_Scholes: I'm not sure why we would want to essentially dilute the tests based on one use case
<jugglinmike> Matt_King: Here, if the screen reader were to speak the name of the container and its role ("mythical university sample content") and spoke the heading overview...
<jugglinmike> James_Scholes: I think the heading overview is an aspect of user experience and shouldn't be asserted. (I think this even though I authored the tests.) The heading is incidental
<jugglinmike> Matt_King: We just wouldn't want anyone to call it "excessive verbosity"
<jugglinmike> James_Scholes: NVDA is quite verbose in ways that goes beyond the heading
<jugglinmike> James_Scholes: [demonstrates NVDA's behavior for this specific case]
<jugglinmike> Matt_King: That is a lot, and it's also similar to what JAWS does
<jugglinmike> James_Scholes: I think there's a big difference between "we incidentally spoke the heading" (I think that's a perfect user experience--just the name, the role, and the heading)
<jugglinmike> James_Scholes: Instead, it completely ignores my "say all" preferences (and the means by which I navigated there)
<jugglinmike> James_Scholes: I find that behavior quite irritating
<jugglinmike> James_Scholes: That's why I'm trying to distill it down into the minimum that would make people happy
<jugglinmike> Matt_King: So James_Scholes is clearly advocating for the "logic" approach; I think if we take that approach, it will be our responsibility to articulate that logic clearly
<jugglinmike> Matt_King: It's not quite like moving with the arrow keys because you're jumping
<jugglinmike> hadi: When you have a "skip to" a specific landmark, they provide different announcements than when you use the landmark navigation
<jugglinmike> Matt_King: I think James_Scholes is saying that it should be the same regardless
<jugglinmike> hadi: What is the difference?
<jugglinmike> James_Scholes: I'm not a JAWS expert, but when you move to a landmark with the R key, it just reads the name and role--not the content
<jugglinmike> James_Scholes: when you use the skip-to link, however, JAWS re-reads the page title, gives an overview of the page, and then starts reading the entire reading as though you were doing a "say all"
<jugglinmike> Joe_Humbert: The reason any screen reader may be doing that is that, generally, if it's done without any scripting, it involves a change in URL, so the screen reader receives a completely different event and handles that differently
<jugglinmike> Matt_King: Brett from Vispero tells me that he's addressed this in the next version of JAWS
<jugglinmike> James_Scholes: Anyway, there is a lot going on. If screen readers have the ability to detect that you clicked a link to move to a thing, they could choose to behave as if you moved to that thing using another navigation technique
<jugglinmike> Matt_King: I think the logic is actually pretty solid
<jugglinmike> Matt_King: This discussion helps me a lot, here!
<jugglinmike> hadi: I'm also thinking it should behave just as James_Scholes suggested. I'm going to think it over some more, though
<jugglinmike> Zakim, end the meeting