Re: [csswg-drafts] [mediaqueries-4] accessibility review [css-a11y] (#1925)

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:

> Meta: the "asides" rendered as tooltips (see for instance the "all", "print", "screen", "speech" in cannot be triggered using the keyboard.

Filed against the tool that generates these asides:

> 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


> 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 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 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".


> 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:

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

> Positive to note that 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, 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.

> A similar "for accessibility reasons" section is present in, 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?

GitHub Notification of comment by frivoal
Please view or discuss this issue at using your GitHub account

Received on Thursday, 28 May 2020 10:04:20 UTC