Implement best practices from A11yFirst

[mgifford]

Build good accessibility defaults

A11yFirst has done a good job highlighting how CKEditor could be built more accessibly. Including elements like:

• User guidance on headings
• Support for Language of Parts
• Show blocks (structural elements) & xpath like display
• Accessible tables (headings/caption/summary)
• Support for decorative, informative & complex images
• Separating block structures vs formatting structures
• A11yFirst Help
• Maybe more... A lot of thought went into this package.

As the We4Authors Cluster highlighted, many accessibility issues are caused by giving the author more authority than they perhaps require.

✔️ Expected result

• All demos of CKEditor 5 don't need to include accessibility, but there should be one that does.
• The default install should be set up for accessibility best practices. Most website builders will just use the default, whatever it is -- so make it inclusive by default.
• Setup the Internationalization Demo to support the Language of Parts - good internationalization support isn't just one of many languages, but many combinations of many languages. CKEditor can do this, so show it.
• Provide support for either axe, or Editoria11y or Sa11y directly.

❌ Actual result

• Well, there aren't a lot of accessibility best practices baked into the demos.
• There seems to be support for Abbreviations, but not a lot of documentation about that
• Not sure what this is about "The spell and grammar check is compliant with WCAG 2.1 and Section 508 accessibility standards."
• "CKEditor 5 provides support for alternate image text" but what is the default? What about decorative, informative or complex images?
• There's talk of using CKEditor 5 plugins to "Adding semantic value to the content, like annotations or accessibility features." but where are they?
• Thanks for catching the color contrast issues in the interface "In this release, several changes were made to improve the accessibility and overall contrast of the UI."

❓ Possible solution

• There is a great example to build on using CKEditor 4 plugins. Use it.
• Focus on making the defaults accessible and it will benefit everyone
• Check for accessibility early in the development process
• Look for ways to be a best practice authoring tool that is following ATAG 2.0 & following the guidance in the We4Authors Cluster study.

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[Comandeer]

I agree that we could incorporate more accessibility tips and info into the documentation of CKEditor 5. There are at least several places that could benefit from that, like Headings demo.

The default install should be set up for accessibility best practices. Most website builders will just use the default, whatever it is -- so make it inclusive by default.

We researched the markup to ensure that it's as accessible as possible. The research included also some basic UI considerations. But I agree that we could revisit some features, like images, and check if we could improve defaults (e.g. connected to images' text alternatives) or at least provide some additional configuration options to force some accessibility features.

There seems to be support for Abbreviations, but not a lot of documentation about that

The Abbreviations plugin is used as an example in the tutorial for creating custom plugins – it's not a "real", official plugin.

Not sure what this is about "The spell and grammar check is compliant with WCAG 2.1 and Section 508 accessibility standards."

The spell and grammar check is provided by WebSpellChecker. You can find more details in their official documentation.

[mgifford]

Accessibility is like security. It requires perpetual vigilance. There are always ways to improve, and that's just part of being tied to working on the internet. 

Editor Recommendations are good. Would be interesting to have for each of them something to see how accessibility has been implemented there. I guess I could do a PR here to illustrate this https://github.com/ckeditor/editor-recommendations

Good to know about the Abbreviations. Nice to have a demo. 

Tracked down the spellcheck to https://webspellchecker.com/wsc-proofreader/

Looking for more information about that claim here WebSpellChecker/wproofreader-ckeditor5#65

[itmaybejj]

I think there is at least some low hanging fruit.

In roughly increasing difficulty order by my guesstimation...

• When you insert a table, it really should include a header row or column by default. Starting with no headers means only power-users know you can make an accessible table. When there is something there and it is wrong, it is intuitive to look for how to change it. This would be a very small, non-breaking change that would not affect any existing content.
• When you insert an image, the alt text window could open by default rather than needing to be clicked. My favorite implementations of this require a decision before closing the field -- e.g., either entering an alt or checking a box affirming that this is a decorative image that does not need an alt. Having the field default to hidden + empty encourages ignoring the field; affirmative actions encourage learning how to write good text alternatives.
• When adding a heading formatting, it would not be too hard to skim the container for existing headings relative to the current object; one could then "mildly discourage" skipped heading levels in the formatting dropdown. But I worry less about this, since skipped heading levels are confusing but less of an outright blocker for screen reader users, as compared to missing alts and table structures.

I do hope to write some sort of Editoria11y adaptation/plugin that can live-check on the fly against the CK5 editor, but I won't be able to start on that until late summer at the earliest. I've gotten it to the point that it can run headless as users edit, but injecting and positioning the tips in a way that looks built-in needs more work.

[mgifford]

@itmaybejj I did get more info from WebSpellChecker: https://github.com/WebSpellChecker/wproofreader-ckeditor5/issues/65#issuecomment-1572501281

[CharlesBelov]

Ideally, a website administrator would be able to block the creation or pasting of complex tables (having rowspan or colspan). This would include removing the ability to join or split cells.

In theory, CKEditor 5 could provide tools to create the accessible markup. However, the process is sufficiently complex that an editor might not be inclined to complete it accurately. Further, we use Tablesaw to make tables displayable on mobile without horizontal scrolling; complex tables break when reformatted..

Specifically with regard to accessibility of complex tables, please see:

Technique H43: Using id and headers attributes to associate data cells with header cells in data tables

and

Technique F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content via the headers and id attributes

[CharlesBelov]

@mgifford, is there a direct link to the source content you refer to in "A11yFirst has done a good job highlighting how CKEditor could be built more accessibly" and "As the We4Authors Cluster highlighted"?

[mgifford]

I think I was referring to this piece here @CharlesBelov https://accessibilitycluster.com/main-results/testing-the-content-of-pages

Too long ago now.

[thegbomb]

For reference, I think this is the repo for the CKEditor4 plugins used in the a11yfirst demo. https://github.com/a11yfirst/plugins-dev, with some documentation here: https://github.com/a11yfirst/design-resources/wiki