Start adding accessibility section to control panel page #745
Conversation
✅ Deploy Preview for craft-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Coming through these changes and taking another stab at the main |
This replaces visual and positional descriptions with a more sensible document-ordered list of features.
This component is upsetting. Why does it apply `aria-describedby` do a random span? Does the <button> even do anything? :( :( :(
|
|
||
| Let’s begin by looking at some key authoring features. | ||
|
|
||
| ## Control panel |
There was a problem hiding this comment.
@AugustMiller I think we should keep the control panel accessibility information limited to one page (or interspersed within the documentation itself), and I'm wondering if it's best to keep it on the control panel page (/5.x/system/control-panel.html), especially if this page is about front-end development documentation related to accessibility (based on the page nesting in the navigation).
| Craft’s [control panel](../system/control-panel.md#accessibility) is [designed and built to be accessible](https://craftcms.com/accessibility), out-of-the-box. | ||
| In addition to built-in interfaces, the content tools you configure for authors are backed by components that we [regularly audit](https://craftcms.com/accessibility/reports) for conformance. | ||
|
|
||
| ### Image editor |
There was a problem hiding this comment.
@AugustMiller I'm wondering if this info can be moved to and combined with the info that's already in the Image Editor section.
Since these details don't affect the accessibility of the front-end, I think we should limit the Image Editor accessibility info to things like the interaction pattern (non-drag abilities for focal point editing, keyboard editing and how to access it, etc.) and either:
- Add an accessibility heading under the Image Editor section that outlines those things, or
- Add an Image Editor heading under the Accessibility section on the control panel page
| {% set tabMap = collect([]) %} | ||
|
|
||
| {# Loop over once to output tabs: #} | ||
| {% for tab in tabs %} |
There was a problem hiding this comment.
@AugustMiller we should probably include the tablist container and additional attributes (or explain that some attributes might be left out for brevity, but to look at the APG example) just so we're promoting the accepted nesting/pattern.
…add extra info about why we do not use a fallback
Description
Adds content related to accessibility features
Related issues
Resolves PT-1906