Much of accessibility issues are in the hands of the authors. Documentation on making accessible content could be provided below textareas and wysiwygs edit areas.
Much of accessibility issues are in the hands of the authors. Documentation on making accessible content could be provided below textareas and wysiwygs edit areas.
Comments
Comment #1
johnbarclay commentedPerhaps the code from the functional accessibility evaluator or other accessibility tools could be used to validate text content. Admins could enable/disable the feature and determine if validation was a must or validation simply produced warnings.
Comment #2
johnbarclay commentedComment #3
kat3_drx commentedIf no one minds, I'm going to try a hook to scan for char limits, line breaks, h1-h6 headings, things like that in content text, before publishing or revisions.
Comment #4
johnbarclay commentedSounds good.
Comment #5
Anonymous (not verified) commentedMuch of this functionality is available in Accessible Content for node edit forms; however, it does not hook into any textareas that are found in admin interfaces, etc. I think it might make sense that this functionality reside in Accessible Helper - maybe you could have an admin setting to set a site-wide default guideline (from the accessible content guideline nodes) and then just use accessible_content_check_string() to check content on form submit.
Comment #6
johnbarclay commentedSeems reasonable. I think it would make more sense to keep such functionality in accessible content. Do you not want it there? I would like see how the accessible content module could be used as an api and this is a great example case.
Comment #7
mgiffordTenon might be an option...
https://github.com/tenon-io/tenon-open-scholar
Comment #8
mgiffordWe might be able to include this as a duplicate #2731373: [upstream] Include an accessibility tester in CKEditor (axe, Tota11y, HTML Code Sniffer)
That is unless we want to either support other WYSIWYG editors...
Comment #9
mgifford