review.state.done.concerns

Treat text track chapters as metadata

[CONCERN] The text track feature was removed from the HTML spec due to lack of implementation in browsers. It has not been removed from the WebVTT spec; it seems helpful for accessibility. There are potentially other UAs that use this feature outside of browsers, as well as JS-based media players that rely on it and work inside browsers.

Remove the concept of "dialog group"

[CONCERN] It seems that the control groups feature (upon which this feature, dialog groups, is built) is what supported the use of F6 to move between panes in a web-app. Whilst this particular feature may have only applied to the dialog element, so unlikely had no impact on accessibility, this is not clear to me, and the related underlying concept of control groups does seem likely to have an impact on accessibility, hence flagging this higher-level feature too.

Remove "control group" concept from the focus model

[CONCERN] It seems that the control groups feature is what supported the use of F6 to move between panes in a web-app. Changing this behaviour would have a bearing on accessibility. Complementary work was underway at W3C ( https://github.com/w3c/html/issues/773 ) and there isn't a clear consensus on what the focusing model should be.

Change <td hidden> to render as display: none

[CONCERN] The problem was that the spec said that td/th elements with the hidden attribute should be rendered as `visibility: collapse` (though this was already overridden as `display: none`). This extra clause was removed. However, `visibility: collapse` content is not displayed visually, but still in the accessibility tree in IE, so this could be an issue for accessibility (though not one that this particular change introduced).

Integrate Feature Policy concepts into HTML

[CONCERN] From reviewing https://www.w3.org/TR/feature-policy-1/ it is not clear to me how much control lies in the hands of the user and how much in the developers. Modern browsers do ask for the user to confirm certain access, but I am not sure if, e.g. autoplay, is covered here. From discussion within APA we feel this could be of great benefit in terms of accessibility if the user is afforded the opportunity to set policies for themselves.

Remove sentences about documents with no focusable area

[CONCERN] Flagging this as this change is a follow-up to the removal of control groups, per 90a60b2a above.

Add "autoplay" policy-controlled feature

[CONCERN] Flagging this as this it follows from the introduction of Feature Policy in 78741b7b above.

Remove the allowusermedia iframe attribute

[CONCERN] Flagging this as this it follows from the introduction of Feature Policy in 78741b7b above. (In and of itself, I don't think this presents an accessibility barrier.)

Make target=_blank imply noopener; support opener

[CONCERN] During APA discussion, we were concerned about the possibility highlighted in the example, where a help page in a separate window could navigate the page that opened it. This pattern could be helpful, but if the page being navigated is in a different window (i.e. process) then someone using assistive technology (e.g. a screen reader or magnifer) may be unaware that the navigation in the other window has taken place.

Add <form rel>

[CONCERN] Flagging as this is a follow-up to 5c68ab3e above.

Remove noopener/noreferrer from tokenizedFeatures

[CONCERN] Flagging as this is a follow-up to 5c68ab3e above.

Define what tabIndex returns when the tabindex attribute is not set

[CONCERN] The list of default-focusable elements in https://www.w3.org/TR/html52/editing.html#the-tabindex-attribute differs with this change (e.g. 5.2 states that audio elements with controls should be focusable, but the audio element is not in the list in this change (I think it's safe to assume that the UA-provided UI should be be focusable, but there could be implications if 5.2 had intended the actual audio element itself to be focusable. If the controls are focusable, then the container maybe need not be, and that could be a win for keyboard accessibility, but I'd like to understand the implications more. This change was updated in the (out of scope for this review) later commit https://github.com/whatwg/html/commit/7ce0b474147ac0574eb3e739f1a9c27e49a249ad (but that one doesn't mention audio elements either). There is discussion about potential new focus-related APIs, which we should track: https://github.com/whatwg/html/issues/1786#issuecomment-504925534