Re: HTML Accessibility Review

Hello all,

I've been making some test cases and doing more research on the areas of concern identified and found that only one is immediately relevant - though there may be another, on which a second opinion may be needed (it's the first of the areas detailed below). There are still several others (as identified, but not as urgent) that I think we'd like to track, also detailed below.

I've updated the HTML WG tracker with our review results: <https://github.com/w3c/htmlwg/issues/5#issuecomment-548994687>

The six other areas, starting with the maybe-accessibility-related one, are as follows. Finally I’ve made a short list of some of the issues I flagged as ‘OK’ that have a bearing on accessibility.


// 1. Tweaks to default tabindex behaviour

Commit: <https://github.com/whatwg/html/commit/15cf23a5>

This removed the concept of "focusable elements" and instead just lists the elements that are expected to be focusable. The list of default-focusable elements in HTML 5.2 (<https://www.w3.org/TR/html52/editing.html#the-tabindex-attribute>) differs, as it includes <audio> and <video> (as well as their browser-provided controls).

Firefox and Chrome both currently place a <video> element in the focus order, as well as its embedded controls. This could be seen as good, as it gives the user a quick way to focus the whole thing, and pressing Space acts as a play/pause control, or it could be seen as bad, as we're adding an extra tab-stop.

It seems too close to call really, but I mention it in case you have any thoughts. From my reading of the HTML repo, this may change in future, but as mentioned, Firefox and Chrome haven't yet.

As an aside: I tested on Firefox and found that <audio> was in the focus order (but the sub-controls all get lumped into one tab-stop—an implementation bug?)


// 2. Treatment of WebVTT "chapters" text-tracks as metadata

Commit: <https://github.com/whatwg/html/commit/4aaacb72>

This changes the behaviour so that the "chapters" `kind` of text track no longer has to be displayed by UAs (because it was never fully implemented).

The WebVTT issue (<https://github.com/w3c/webvtt/issues/344>) is still open; there was concern about removing the "chapters" `kind` from HTML entirely because JS-based players in browsers use it (and it's still regarded as a useful feature in the main WebVTT spec). Therefore the change to the HTML spec involved keeping "chapters" as a valid `kind` value, so the JS-based player still work, but equating it to the "metadata" value (not to be displayed visibly by UAs).

Therefore this is not actually an immediate concern, but it would be good to see if there's anything we can do to help get chapters implemented in future.


// 3. Removal of dialog/control groups

The F6 shortcut for moving between control/dialog groups was never implemented, and the concepts of dialog and control groups were not used elsewhere, hence their removal. However, it was under discussion in an issue on the W3C repo <https://github.com/w3c/html/issues/773/> and is ongoing in an issue in the HTML repo <https://github.com/whatwg/html/issues/1929>.

There are three related commits:
https://github.com/whatwg/html/commit/a4bb3465
https://github.com/whatwg/html/commit/90a60b2a
https://github.com/whatwg/html/commit/b2ff9c72


// 4. Feature Policy

This approach sounds like it has great potential to improve accessibility, and seems relevant to the Personalization Task Force's work. Initially I was concerned due to the removal of the `allowusermedia` attribute, but I've been able to verify this was never implemented, so isn't relevant.

I had two questions, both of which further research within APA should be able to answer, and neither of which are urgent for this review...

1. Is it expected (or specced somewhere) that UAs would provide a UI to allow the user to enable/disable any Feature Policy-controlled features, or is it left up to the UAs? (I think the answer is no, as not all browsers do).

2. I'd also be interested as to if browsers might ultimately expose an API that would allow an agent acting on the user's behalf to make such settings changes, but here we are well beyond the bounds of this review and we can do more research to answer these questions.

There are three related commits:
https://github.com/whatwg/html/commit/78741b7b
https://github.com/whatwg/html/commit/f23329e0
https://github.com/whatwg/html/commit/95e72ce3


// 5. IE issue with visibility: collapse

This was brought up by the commit "`<td hidden>` should render as `display: none`" <https://github.com/whatwg/html/commit/b3c7c89e>

The spec had said that `<td>`/`<th>` elements with the `hidden` attribute should be rendered as `visibility: collapse`, though this was changed to `display: none` in this commit.

At some point before this, `tr[hidden]` was specced to use `visibility: collapse`, though IE still uses `display: none`.

IE exposes `visibility: collapse` content in the accessibility tree (other mainstream browsers don't). [Thanks to Steve Faulkner for checking that out.]

I don't imagine that we could even get this changed by filing bugs, but as it came out of the review I thought I'd note it.


Finally, some of the commits I'd flagged as OK in my review sound interesting for accessibility, so I'll make a short list here.

* The idea of having a single point on which to add event listeners for when a custom element is activated (by keyboard, mouse, touch, ...) was raised in the PR thread related to commit <https://github.com/whatwg/html/commit/35e3e1ec>.

* A good UX use-case for using the `preventScroll` option of the `element.scroll()` function was given: when using a TV and a remote to point at things, they get the focus automatically. However, scrolling to the items could easily cause the UI to jump around a lot (as per the comment <https://github.com/whatwg/html/issues/834#issuecomment-295643901>; original commit reviewed was <https://github.com/whatwg/html/commit/7a579c1c>). I wonder if this would be helpful for eye-gaze control.

* The xxx-large font size was standardised in <https://github.com/whatwg/html/commit/83d5bec4>.

* Noting that the "enter key hint" provided on software keyboards would need to provide an accessible name if visually it's only using an icon <https://github.com/whatwg/html/commit/a5422d98> (of course that's down to the implementation, not the spec under review).


I think that concludes things for now; please let me know if you feel the first of the issues above is something that needs to be addressed, or if you have any questions.

best regards,


Matthew
-- 
Matthew Tylee Atkinson
--
Senior Accessibility Engineer
The Paciello Group
https://www.paciellogroup.com
A Vispero Company
https://www.vispero.com/
--
This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.

Received on Saturday, 2 November 2019 10:56:32 UTC