[mediaqueries-4] accessibility review [css-a11y]

[IanPouncey]

Reviewed on behalf of the CSS Accessibility Task Force by @patrickhlauke.

My best effort review of the spec (and I'll mention right away that I myself contributed to the spec, including the addition of some of the accessibility/keyboard related notes, so I'm biased):

Meta: SVG diagrams should be given a role="img" and appropriate description

Meta: the "asides" rendered as tooltips (see for instance the "all", "print", "screen", "speech" in https://www.w3.org/TR/mediaqueries-4/#media-types) cannot be triggered using the keyboard.

https://www.w3.org/TR/mediaqueries-4/#media-types note that "tty", braille", "embossed", aural" etc are deprecated, due to no UA supporting them. However, "speech" is still maintained active. There is, to my knowledge, no evidence of UAs actually presenting themselves as "speech" type devices. Raised the issue here #1751

Interaction media features https://www.w3.org/TR/mediaqueries-4/#mf-interaction are based on the idea that devices/user agents have a "primary" pointing device. The non-normative notes suggest that user agents may have heuristics or user settings so that for keyboard users the queries for pointer:none (absence of a pointing device) should evaluate to true even if there are pointing devices (like a mouse or touchscreen) present. Note that, to my knowledge, no user agent currently does this/offers any kind of setting or heuristic.

The spec aknowledges that it does not include an equivalent media feature to detect the presence of a keyboard / keyboard-like interface, but includes a note suggesting that authors should "take into account the potential presence of non-pointing device inputs, regardless of which values are matched when querying these features".

Positive to note that https://www.w3.org/TR/mediaqueries-4/#pointer details how user agents should treat user zoom with regards to pointer accuracy - zoom does not influence the exposed value (e.g. a "coarse" pointer like a touchscreen does not suddenly become "fine" like a mouse when the user is zoomed in / the targets become visually bigger).

This section also includes a "for accessibility reasons" section which hints at the possiblity that UAs would expose pointer accuracy as being coarse (or no primary pointer being present) despite a fine pointer being present (meta: this should probably be in a non-normative note). As above, tote that no user agent currently does this.

A similar "for accessibility reasons" section is present in https://www.w3.org/TR/mediaqueries-4/#hover, hinting that UAs may not expose the hover capabilities of the primary pointer if hovering is inconvenient for the user. Same note as before on lack of actual UA support for this.

https://www.w3.org/TR/mediaqueries-4/#any-input non-normative notes strongly mention the limitations of these media features in detecting keyboard users, and make recommendations to authors to still consider these users / not assume that these features (e.g. the fact that the media feature checks for pointers or hover capability) imply that all users will actually be using those potentially available input methods.

https://www.w3.org/TR/mediaqueries-4/#priv-sec covers the potential aspects of more accurately fingerprinting users. Worth noting that none of the media features would directly constitute a way to identify users with disabilities, with the exception of the "speech" media type https://www.w3.org/TR/mediaqueries-4/#valdef-media-speech. As I don't think there are any actual UAs that identify as "speech" type devices in the wild anyway, and due to the potential problem of "screenreader detection", I'd recommend officially deprecating this media type along with the already deprecated "tty", "braille", "aural" (again, see #1751)

[frivoal]

Thanks for the feedback, and sorry for the (very) belated answer. Your patience and understanding is appreciated.

Meta: SVG diagrams should be given a role="img" and appropriate description

Filed against the tool that generates these SVG images: speced/bikeshed#1680

Meta: the "asides" rendered as tooltips (see for instance the "all", "print", "screen", "speech" in https://www.w3.org/TR/mediaqueries-4/#media-types) cannot be triggered using the keyboard.

Filed against the tool that generates these asides: speced/bikeshed#1681

https://www.w3.org/TR/mediaqueries-4/#media-types note that "tty", braille", "embossed", aural" etc are deprecated, due to no UA supporting them. However, "speech" is still maintained active. There is, to my knowledge, no evidence of UAs actually presenting themselves as "speech" type devices. Raised the issue here #1751

and

https://www.w3.org/TR/mediaqueries-4/#priv-sec covers the potential aspects of more accurately fingerprinting users. Worth noting that none of the media features would directly constitute a way to identify users with disabilities, with the exception of the "speech" media type https://www.w3.org/TR/mediaqueries-4/#valdef-media-speech. As I don't think there are any actual UAs that identify as "speech" type devices in the wild anyway, and due to the potential problem of "screenreader detection", I'd recommend officially deprecating this media type along with the already deprecated "tty", "braille", "aural" (again, see #1751)

Handled as #1751, where we did agree with your recommendation to deprecate this media type.

Interaction media features https://www.w3.org/TR/mediaqueries-4/#mf-interaction are based on the idea that devices/user agents have a "primary" pointing device. The non-normative notes suggest that user agents may have heuristics or user settings so that for keyboard users the queries for pointer:none (absence of a pointing device) should evaluate to true even if there are pointing devices (like a mouse or touchscreen) present. Note that, to my knowledge, no user agent currently does this/offers any kind of setting or heuristic.

That section has been discussed to great detail, and the current version is the compromised we landed on. If implementers do not want to follow the specification and want to do something else, they should say so. If there are arguments that have not been taken into account in the current compromise, they should be raised as separate issues. Until them, I am not sure what to do other than assume that the currently specified text remains the agreed target.

The spec aknowledges that it does not include an equivalent media feature to detect the presence of a keyboard / keyboard-like interface, but includes a note suggesting that authors should "take into account the potential presence of non-pointing device inputs, regardless of which values are matched when querying these features".

and

https://www.w3.org/TR/mediaqueries-4/#any-input non-normative notes strongly mention the limitations of these media features in detecting keyboard users, and make recommendations to authors to still consider these users / not assume that these features (e.g. the fact that the media feature checks for pointers or hover capability) imply that all users will actually be using those potentially available input methods.

This remains an area of open discussion. detecting the presence of keyboard(s) and their characteristic is undoubtedly desirable, but the right way to address this problem still escapes us. Documenting use cases that would benefit from being able to query about keyboards would certainly help understand the problem space better, and a contribution on that topic from an accessibility point of view would be most welcome. Open issues to track the need for this additional feature include:

• Request: media query feature for device when a virtual keyboard is open/closed #621
• [mediaqueries-5] detect keyboard navigation abilities #1911
• [mediaqueries-5] Detect physical keyboard (keyboard capable of shortcuts?) #3871
• [css-media-queries] Orientation does not respect soft keyboard on mobile devices #3587

Until this is solved, reminding authors that there might be a keyboard seems the best we can do.

Positive to note that https://www.w3.org/TR/mediaqueries-4/#pointer details how user agents should treat user zoom with regards to pointer accuracy […]

I take this comment as supportive, and not requesting any change.

A similar "for accessibility reasons" section is present in https://www.w3.org/TR/mediaqueries-4/#hover, hinting that UAs may not expose the hover capabilities of the primary pointer if hovering is inconvenient for the user. Same note as before on lack of actual UA support for this.

and

A similar "for accessibility reasons" section is present in https://www.w3.org/TR/mediaqueries-4/#hover, hinting that UAs may not expose the hover capabilities of the primary pointer if hovering is inconvenient for the user. Same note as before on lack of actual UA support for this.

The normative text is a "may". This is merely intended to give permissions to UAs to follow that behavior to accomodate certain user preferences or needs. Even if no (known) UA currently takes advantage of it, the logic remains valid.

---

In conclusion, I believe that the issues that are caused by limitations of the tool used to produce the specification (and which is shared with every other specification), should be looked into and addressed, so I have filed them separately.

As for the other points you raised, I do not believe that there remains any particular action to be taken in the specification; either it has been done already, or it is tracked as a separate feature request, or the discussion had in this issue brings a sufficient conclusion.

If you disagree and believe that there remains some thing that needs to be addressed in the specification, may I request that you open individual issues for each point you would like to follow up on?

[frivoal]

Marking this as closed as I believe all the points raised have been answered, but I would appreciate if you could confirm. If you believe I did not respond adequately, you may of course reopen, although as mentioned above, individual issues would facilitate tracking and resolution.

[frivoal]

(pinging @patrickhlauke, since this was filed on your behalf)

[patrickhlauke]

Thanks @frivoal yes, this all seems addressed (and the metas/asides about SVG and tooltips filed separately aren't blockers here for this).

The points about interaction media features were more meant as clarification/summary for those not too closely involved with the discussion. Agree that it's now up to UAs to do something about it (incidentally, and separately, have been testing these recently in different scenarios https://patrickhlauke.github.io/touch/pointer-hover-any-pointer-any-hover/results/). Ditto the longer discussion about keyboard, which again I agree is something more fundamental and tricky. Agree that the current wording/mention of keyboard/etc is the best compromise for now.

Long story short, it all sounds good to me and yes, good to close.