Open mgifford opened 1 year ago
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.
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
I think there is at least some low hanging fruit.
In roughly increasing difficulty order by my guesstimation...
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.
@itmaybejj I did get more info from WebSpellChecker: https://github.com/WebSpellChecker/wproofreader-ckeditor5/issues/65#issuecomment-1572501281
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:
and
@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"?
I think I was referring to this piece here @CharlesBelov https://accessibilitycluster.com/main-results/testing-the-content-of-pages
Too long ago now.
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
Build good accessibility defaults
A11yFirst has done a good job highlighting how CKEditor could be built more accessibly. Including elements like:
As the We4Authors Cluster highlighted, many accessibility issues are caused by giving the author more authority than they perhaps require.
✔️ Expected result
❌ Actual result
❓ Possible solution
If you'd like to see this fixed sooner, add a 👍 reaction to this post.