Bug 34543 - Content block accessibility helpers
Summary: Content block accessibility helpers
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords: Academy
Depends on:
Blocks: 23003
  Show dependency treegraph
 
Reported: 2023-08-16 13:01 UTC by Martin Renvoize (ashimema)
Modified: 2024-10-21 09:52 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize (ashimema) 2023-08-16 13:01:32 UTC
With the ability to enter almost anything into the HTML Content blocks, and especially the WYSIWYG editor used.. it's very, very easy to break the accessibility of your OPAC.

We should look into options for hinting at correct headings level start point in the editor and perhaps add options for adding simple styled blocks that conform to Koha best practices (Like the use of page-sections in intranet blocks for example)
Comment 1 Martin Renvoize (ashimema) 2023-08-16 13:07:19 UTC
TinyMCE actually have an accessability checker tool.. though it looks like a premium plugin to me.. likely licensed?

https://www.tiny.cloud/docs/tinymce/6/a11ychecker/
Comment 2 David Cook 2023-08-16 23:34:54 UTC
It's an interesting idea. 

I've been adding element/attribute filtering to the HTML Content blocks, so the UI for this is certainly on my mind these days...
Comment 3 Philip Orr 2024-10-21 09:34:18 UTC
Maybe out of scope of this bug, but:
If the WYSIWYG editor can cause problems with accessibility especially for HTML customizations for the OPAC, would it be better to be able to choose Texteditor / Codemirror specifically only for HTML customizations and WYSIWYG for "everything else"?
The way it is currently, system preference AdditionalContentsEditor sets the default editor for all additional contents, so news, HTML customizations, etc.
Maybe it would be better to separate the HTML customizations and pages part into a new system preference?
Comment 4 Philip Orr 2024-10-21 09:52:39 UTC
I added a new bug for my previous comment:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38218
as it's probably out of scope here :)