Replies: 5 comments 7 replies
-
The problem with using checkbox hack for showing the sidebar (e.g. Heydon Pickering has a working example of accessible dropdown menu using checkbox hack, see codepen and inclusive-components article. However, to retain the expected behaviour here using an anchor link to the drawer container (using Here's a "fallback" example codepen that would be enhanced using javascript to have all relevant aria attributes, behaving mostly like a disclosure pattern with a bit of dialog pattern. |
Beta Was this translation helpful? Give feedback.
-
Having all the Switch to [option] (dark/light/system preferences) radio |
Beta Was this translation helpful? Give feedback.
-
Thanks for reporting. Accessibility is an ongoing effort and a priority for this project. I try to make it as accessible as possible, but I understand that there are some things (e.g. the checkbox "hack") for which improvements might need fundamentally different solutions with other downsides, as you already noticed. I'm regularly testing the theme by using a screen reader, but I'm not a regular user of those, so I can only guess whether it works well enough. My comments for the things you already mentioned:
My testing in Chrome and Firefox shows that this is exactly possible. Please provide more details when you don't find this to be working. I can Tab to the selector and then use the arrow keys to toggle between the different states. Also note that all toggles are grouped inside a
If you come up with a better solution or manage to integrate the one you posted without any loss in functionality, I'm happy to merge it. Please see #4006 (comment) for further implementation details. I'm converting this issue to a discussion, which we can branch out into PRs and issues, if necessary. You can create issues for missing |
Beta Was this translation helpful? Give feedback.
-
I'd like to join this discussion, a year and a half later, to mention that the problem with the color scheme switch (dark/light/system) still poses a challenge for a specific group: sighted keyboard users. These users rely on the keyboard to move around and use their eyes to perceive the content. The color scheme switch looks like a button but doesn't have a label. Because it looks like a button, keyboard users would think they could activate it using the Enter key. However, pressing the Enter key doesn't do anything. Also, without a clear label, the button's purpose is confusing. In short, users in this group might think the button is broken. Since these users don't use a screen reader, they don't hear any announcements about this component being a radio selector. Furthermore, because they don't use a mouse, they can't see the tooltips explaining this component's function when hovering over it. It would be great to address this problem to improve keyboard accessibility. |
Beta Was this translation helpful? Give feedback.
-
I just set up some CI to test our docs accessibility against the Search plugin lacks a submit button
I don't think this is an issue since the search bar doesn't need a submit button (it auto-loads results as an extension of the search bar which are then accessible via the keyboard).
Checkbox input doesn't have a name
I assume this is the "hack" mentioned earlier in the discussion
Form field needs filling
Is this also the "hack" mentioned earlier in the discussion?
Code line href without link content
This appears irrespective of the code content features that are switched on.
Insufficient contrast
I know this is something that a user can configure, but these are results using the out-of-the-box mkdocs Material theme, so I feel they should be accessible by default.
|
Beta Was this translation helpful? Give feedback.
-
Contribution guidelines
I've found a bug and checked that ...
mkdocs
orreadthedocs
themescustom_dir
,extra_javascript
andextra_css
Description
There are a number of sub-optimal implementations for accessibility, and some misuse of ARIA roles, particularly around navigation (e.g. sidebar) and search.
This causes some major difficulties for keyboard navigation.
Whilst #4006 touches on a few issues, I'd like to build this into a Meta issue to document the existing issue, the challenges they cause and potential directions to ensure improved accessibility.
To that effect, I'll be slowly adding as I go, so this is a WIP bug report.
Expected behaviour
Ability to navigate, use and interact with menu (on narrow screen), search and operate interactive components using keyboard and assistive technology.
Actual behaviour
Steps to reproduce
Use keyboard to tab through page elements.
Package versions
python --version
mkdocs --version
pip show mkdocs-material | grep -E ^Version
Configuration
System information
Beta Was this translation helpful? Give feedback.
All reactions