Clarify that Baseline does not cover assistive technology #519
Conversation
This adds an item to non-goals to clarify that support in assistive tools that may be used along a browser is not (yet?) covered by Baseline. See discussion in #498
docs/baseline.md
Outdated
| @@ -176,5 +179,6 @@ Here are some areas for future consideration and not currently in-scope for Base | |||
| * Progressive enhancement safe (i.e., limited penalties for support failures) | |||
| * Developer feedback requested | |||
| * Buggy (e.g., supported but in ways that are surprising and semi-interoperable) | |||
| * Buggy or unsupported in assistive tools | |||
There was a problem hiding this comment.
Because this is a future consideration and Baseline is not going to add AT support, I suggest something a bit more straightforward as a future goal (since it keeps the scope strictly with browsers and does not require AT):
"Confirm if features are exposed to platform accessibility APIs (AAPIs) as specified."
There was a problem hiding this comment.
I reformulated, but my goal here was to minimize changes and this is more a list of candidate baseline states than a generic list of areas for future consideration. I merged the two "Buggy" bullets into one, using your wording.
|
This touches the baseline definition so needs to be approved by current owners, flagged as reviewers accordingly. |
docs/baseline.md
Outdated
| @@ -175,6 +178,6 @@ Here are some areas for future consideration and not currently in-scope for Base | |||
| * Upcoming (e.g., not yet shipped in all browsers) | |||
| * Progressive enhancement safe (i.e., limited penalties for support failures) | |||
| * Developer feedback requested | |||
| * Buggy (e.g., supported but in ways that are surprising and semi-interoperable) | |||
| * Buggy (e.g., supported but in ways that are surprising and semi-interoperable, not exposed to platform accessibility APIs (AAPIs) as specified) | |||
There was a problem hiding this comment.
I think I'd make accessible a separate bullet point, since something could be fully interoperable for non-AT users and fully unsupported in AT (I hope we don't have features in that state, but I still think it makes sense to make "accessible" a top level item rather than a sub-case of generally buggy).
There was a problem hiding this comment.
Done. To be clear, I don't necessarily think that Baseline should have a dedicated state for that. I was more using the list to make explicit that exposure to platform accessibility APIs is one of the areas that should be taken into account once we have enough support data.
There was a problem hiding this comment.
My interpretation of this is that if the browser doesn't expose the correct information to the accessibility tree, or if there are bugs in the mapping, that is in scope for Baseline. It's a user-affecting issue, and in some cases could be serious enough to say a feature isn't Baseline.
What is out of scope is bugs outside of the browser, in the operating system or ATs.
To refine the policy beyond that we'd need examples of features that have the wrong Baseline status, where an accessibility issue should lead to the feature to be considered notBaseline.
Co-authored-by: Daniel D. Beck <[email protected]>
Co-authored-by: Philip Jägenstedt <[email protected]>
|
@ddbeck This seems good to go. Anything blocking merge? |
Co-authored-by: Philip Jägenstedt <[email protected]>
|
Applied and merged! |
This adds an item to non-goals to clarify that support in assistive tools that may be used along a browser is not (yet?) covered by Baseline.
See discussion in #498