Accessibility

[NickColley]

Has this feature had any accessibility considerations? I've searched this repository and discussions and not seen any thoughts on how this might impact disabled people, for example what impact it could have on screen readers.

This is worrying given it looks to be a live feature in Chrome when using Google Search links.

[bokand]

We've definitely thought about it and ensured it works correctly with Chrome's accessibility features; happy to take bugs if you've found anything specific.

Admittedly, the spec/explainer is embarrassingly lacking in describing the few issues we've come across. I'll update that soon.

[NickColley]

ensured it works correctly with Chrome's accessibility features

Can you give more detail on what was tested?

[bokand]

The main issue I recall was making sure it works correctly with screen readers and that the reader starts from the loaded location on the screen.

[NickColley]

Do you know what the result was? What screen readers were involved in the testing?

[bokand]

I'd have to look it up, I wasn't the one who worked on it, but IIRC it was Android's TalkBack reader. Is there anything specific you're getting at?

[nickburris]

Here's the related bug FYI: crbug.com/1044644, I confirmed that it works with TalkBack. It behaves the same as element anchors, the screen reader's position is set to the node that the match is found in.

[NickColley]

I guess I'm worried that there has not been tested with screen readers people use and this feature is currently in production so it could be creating barriers for disabled people.

In the WebAIM survey shows lots of usage of NVDA, JAWS, VoiceOver etc.
https://webaim.org/projects/screenreadersurvey8/

You'll find that screen readers can behave very differently so this should be tested in more than just TalkBack to be sure.

[bokand]

As Nick mentioned, this piggy-backs on functionality provided by element-id anchors which have been around forever so I expect if readers worked with that it'd work here as well. UI-wise, this feature doesn't really have much new to it, it mostly ties together existing functionality. That said, I can try it out on some desktop readers to be sure.

[NickColley]

Given the fact that Google Search is used by billions of people I think it's vital to check this.

[bokand]

Just to be clear, I'm speaking mainly for my own experience. The feature was vetted (as all features are) and approved by the Chrome accessibility team prior to shipping; I just don't have a ton of visibility into that process.

[ghost]

Hi all! @bokand @nickburris @NickColley
I thought of something accessible and private: "Ideas for better accessibility and privacy"

[ghost]

Hey there!

I don't know if this can help. It is not a statement but a question. Have you all thought about providing an open api to support different screen readers?

Well... I ask about that, because there are several screen readers, and in this case it should be possible to make some "open" partnership with the objective of improving products or services... to solve this problem present here.

[jcsteh]

As noted above, as implemented in Chrome, assistive technology should be notified that the page has scrolled to the start of the first text directive, in the same way as this is done for element-id anchors. This will cause screen reader cursors to move to that point on the page. However:

1. This is not documented anywhere in the explainer.
2. There is no way for an assistive technology user to perceive the exact text which is visually highlighted. They only know about the node in which the text begins.
3. There is no way for an assistive technology user to perceive any text directives other than the first.

So, as things stand, significant parts of the feature are completely inaccessible to users who depend on accessibility APIs.

[bokand]

Sorry for the delay.

Yeah, agree with all those points. Though I don't know: is this something at the level of the feature specification or are these kinds of accessibility APIs specified elsewhere? Or is this up to individual user agents to provide proprietary APIs to assistive tech?

Unfortunately I'm not well versed here but if you (or anyone) could point me in the right direction I can help move things in this direction.

[jcsteh]

The accessibility mappings absolutely need to be included in a public spec. Precisely where they are included depends somewhat on where the bulk of the feature is specified. For example, for HTML elements, the accessibility API mappings are specified in the HTML Accessibility API Mappings. Where something can't be generalised like HTML elements, it is sometimes documented in the spec itself. For example, CSS content-visibility has an Accessibility Implications section.

I'm not sure whether there are plans to move the URL Fragment out of WICG and into some other spec. If not, this needs to at least be documented in the WICG spec, since there's nowhere else it can be documented.

[bokand]

Thanks for the links @jcsteh! That makes sense, I'll have to have a closer look at those but if there's some spec-defined hooks for assistive tech then we should definitely include that as well.

The goal is to shape up the spec here and then merge it into WHATWG HTML. Unfortunately I'm on leave for the next ~2 months but will try to pick it back up when I return. (Also happy to accept PRs) Thanks!

[zcorpan]

The main issue I recall was making sure it works correctly with screen readers and that the reader starts from the loaded location on the screen.

I think this aspect doesn't work currently for macOS VoiceOver, see https://bugs.webkit.org/show_bug.cgi?id=278103