Make CMS-UI inclusive and accessible

[Wagner3UB]

PLIP (Plone Improvement Proposal)

Adding the capability for people using a keyboard or assistive technologies to add/edit content or use the controlpanels.

Responsible Persons

Proposer: @Wagner3UB

Seconder: @pnicolli

Abstract

This PLIP proposes improving the Plone CMS user interface (CMS-UI) to ensure accessibility and inclusivity. The focus will be on enabling users who rely on keyboards or assistive technologies to add and edit content and navigate control panels effectively. The goal is to align the CMS-UI with modern accessibility standards, enhancing the overall user experience.

Motivation

Plone is committed to being an inclusive platform. While the CMS already offers some accessibility features, there are limitations for users who depend solely on keyboards or assistive devices. Enhancing the CMS-UI for these users ensures that Plone continues to serve a diverse audience and complies with global accessibility standards, such as WCAG. Accessibility improvements will also foster broader adoption and demonstrate Plone’s commitment to equitable digital experiences.

Assumptions

• Users may rely on various assistive technologies, including screen readers, switch devices, and alternative input methods.
• Plone’s UI components need refinement to fully support keyboard navigation and meet ARIA (Accessible Rich Internet Applications) requirements.
• Developers and designers involved in this project will follow best practices in accessibility.

Proposal & Implementation

1. Audit the CMS-UI: Conduct an accessibility audit to identify areas that require improvement, focusing on navigation, form handling, different use cases for blocks and content types, modals, control panels and sidebars/toolbars handling.
2. Implement Keyboard Navigation: Ensure that all interactive elements, such as buttons, links, menus, and forms, are accessible via keyboard.
3. Add ARIA Roles and Labels: Integrate ARIA attributes to provide context and improve compatibility with screen readers.
4. Implement and promote the use of Adobe Aria Components while gradually phasing out Semantic-UI.
5. Color Contrast & Focus Indicators: Review and adjust color contrast and add clear focus indicators for interactive elements.
6. Testing and Feedback: Collaborate with users of assistive technologies to validate improvements through real-world testing.
7. Documentation: Update Plone’s accessibility documentation to reflect changes and provide guidelines for future development.
8. Specific guideline: Provide documentation with use cases, such as focus and minimal contrast for the main font color, links, and buttons (+). Additionally, include a list of used colors, font sizes, and border widths (+)

Deliverables

• A fully accessible CMS-UI that complies with WCAG 2.1 standards.
• Comprehensive documentation on accessibility improvements and usage.
• Automated and manual test cases focusing on accessibility.

Risks

• Increased Complexity: Accessibility enhancements may introduce complexities in the UI codebase, potentially requiring more maintenance.
• Time and Resources: Ensuring thorough testing and validation may require additional time and resources.
• Browser Compatibility and assistive technologies: Ensuring consistent behavior across different browsers and assistive technologies may present challenges.

Participants

• @stevepiercy for documentation
• @ichim-david as member of the A11Y Team
• @JeffersonBledsoe as member of the A11Y Team
• @Wagner3UB as member of the A11Y Team

Issues and related PR's

At this moment it's possible to use the label: "99 tag: UX Accessibility" to find most of the issues and PR's.

TODO: An improvement in the way items related to accessibility and inclusion are cataloged is necessary.

PR's

#6361
#6358
#6356
#6346
#6345
#6344
#6329
#6318
#6314
#6318
#6314
#6025
#5732
#5392
#5273
#5271
#4781
#4773
#4600
#4147
#3912
#3491

Issues

#6336
#6341
#6348
#6304
#6303
#5731
#5617
#5466
#5400
#5396
#5269
#5268
#5221
#5212
#5211
#5204
#5203
#5150
#5148
#5147
#5144
#5143
#5142
#5141
#5140
#5129
#5127
#5125
#5123
#5122
#5121
#5119
#5118
#4982
#4771
#4770
#4747
#3679
#2544
#2543
#2485
#1508
#1507
#1506 - To confirm if it needs more attention
#1384
#770 - To confirm if it needs more attention
#301 - To confirm if it needs more attention

[tisto]

@Wagner3UB +1 from me!

I am wondering if the ATAG guidelines are relevant here?

https://www.w3.org/WAI/standards-guidelines/atag/

@sneridagh please make sure that the @plone/volto-team votes on this at the next meeting.

[stevepiercy]

Proposal & Implementation

7. Documentation: Update Plone’s accessibility documentation to reflect changes and provide guidelines for future development.

Update to:

7. Documentation: Update Plone’s accessibility documentation to reflect changes and provide guidelines for future development. WIP Update a11y guidelines #6361.

Issues and related PR's

TODO: An improvement in the way items related to accessibility and inclusion are cataloged is necessary.

What improvements do you want that the current label does not do?

[stevepiercy]

We also need to align how we market Plone with this PLIP. See https://plone.org/accessibility

[JeffersonBledsoe]

I am wondering if the ATAG guidelines are relevant here?

Makes me happy hearing ATAG mentioned! It's not discussed as much as it should be.
As a generalisation, the ATAG guidelines are essentially WCAG for the editor + making sure the content produced by the CMS is accessible + having tools within the editing environment to check & fix accessibility issues with content.
That said, we still have alot of work to do to in meeting the WCAG compliance side so should focus in on that!