SimpleMachines
Accessibility
Description
The accessibility for SMF is very worse.
Some HTML elements have an attribute tabindex with a value greater than 0. With HTML 5 the tabindex make HTML elements as DIV or SPAN focusable if the tabindex is 0. Other values are not allowed and tabindex shall not be used on form elements as input, button, select or textarea. Furthermore, applying a tabindex greater as 0 make such elements unreachable.
Form elements (input, ...) shall be labeled, at least, with aria-label.
Replacing some div element with header, main, section, article and footer shall improve the accessibility.
The foldable parts (categorie, ,,,) may use the details and summary HTML elements with the advantage, that less javascript is necessary and more accessible.
Some People has a motor deficiency and are not able to use a mouse. For such people, focusable elements shall be optically shown if focused. For links, the default underlining for the text is a worse idea, there is not enough recognizable difference and the text may be less readable.
The color contrast for the default theme is poor and don't fulfill the WCAG requirement.
Steps to reproduce
Try to reach the various elements via the keyboard, this don't work.
Environment (complete as necessary)
- Version/Git revision: 2.1.3
- Database Type: not relevant
- Database Version: not relevant
- PHP Version: not relevant
Additional information/references
Connecting up the forum topic: https://www.simplemachines.org/community/index.php?topic=584355.0
Connecting up the forum topic: https://www.simplemachines.org/community/index.php?topic=584355.0
By the way, on Linux you can check the screenreader output with orca, in Apple systems with voiceOver and of the nit true OS Windows with Narrator. For Mac and Windows the screen readers must only be enabled for Linux Systems you should install orca. For Windows there are also NVDA (open source) which seem to be often used and JAWS a commercial product.
Colors: I think that it will be good to have a css file with the definition of the used colors which can be used with, for example; "background-color: var(--cat-bg-color)". This may be usefull for people which wan't do have other color rendering or modify from light to dark UI.
This is an important issue, and addressing it will require fairly extensive changes to the theme files.
Since the development policy for SMF is that the default theme should remain as stable as possible across patch releases (meaning, no changes unless absolutely necessary to fix a bug), a major rewrite of the default theme in a patch update is not possible.
Instead, there are two possible ways to address this issue:
-
Revise the default theme to address these issues in SMF 2.2. This would make a good argument for accelerating the release of 2.2 (as opposed to more 2.1.x patches) as much as possible.
-
Release a second official theme for SMF 2.1.x that addressed these issues. This second theme would not technically be the default, so far as the inner workings of SMF's theme system would be concerned, but it could be the one that is selected by default.
I'm sure there are some helpful things doable in 2.1.x. E.g., the forum request referenced above is only for an aria label on the editor.
It would be helpful to get a specific, prioritized list. It would be more actionable.
I know we have blind users on my forum, but they have never asked for forum changes; when they ask for help it has been for understanding diagrams, tables in technical pdfs, forum attachments.
Do these fail using Chrome's Lighthouse check or is there another tool to assist us here?
I'm sure there are some helpful things doable in 2.1.x. E.g., the forum request referenced above is only for an aria label on the editor.
Yes, I suppose just adding attributes to the existing HTML markup should be fine. Changing the tabindex attribute values might okay, but more thought would be needed before deciding on that. Beyond that, though, things get problematic. Any structural changes to the HTML would inevitably break custom themes, and any non-trivial changes to the underlying PHP logic in the theme files would have to be very carefully considered for the same reasons.
Do these fail using Chrome's Lighthouse check or is there another tool to assist us here?
Lighthouse cover only some aspects, manual test are all way required.
Alternative, which can be installed on chromium or Firefox, are the WAVE tools. The name of the extensions is not filly the same for Firefox and chromium based browsers (Google-Chrome, Edge, ...)
WCAG Color contrast checker / WCAG Contrast checker WAVE Accessibility Extension / WAVE Evaluation Tool
Some things are feasible on 2.1 For my own, I have a copy of the default theme and added some files from the default. PHP:
- file containing tabindex, with removing the tabindex or setting this to 0 for the first time.
- added on the span for folding/unfolding a tabindex 0 and moved the span dexlaration after the title (lofical order)
JS:
- copied Srcipt.js and added an even thandler (keypress) after the click event within smc_Toggle.prototype.init()
oImage.onkeypress = function (ev) { if ( !(ev.keyCode == 13 || ev.keyCode == 32) ) return false; this.instanceRef.toggle(); this.blur(); }for searching, added 2 aria-label to the searching using texts provided within the language files (search and search_for)
Of course, the theme CSS file are adapted to my requirement.
These modifications should not be incompatible with the actual 2.1.3 code.
I'm sure there are some helpful things doable in 2.1.x. E.g., the forum request referenced above is only for an aria label on the editor.
Yes, I suppose just adding attributes to the existing HTML markup should be fine. Changing the tabindex attribute values might okay, but more thought would be needed before deciding on that. Beyond that, though, things get problematic. Any structural changes to the HTML would inevitably break custom themes, and any non-trivial changes to the underlying PHP logic in the theme files would have to be very carefully considered for the same reasons.
The tabindex mimic don't anymore work, so removing tabindex from form elements as input, ... will make them reachable. I don't think that this may affect other themes. Furthermore, if an accessible theme is provided, it may contain a modified copy of the default php files.
Setting aria-label for the textarea should probably be done within the theme.js script.
for each element with class cat_bar
search for textarea under the cat_bar parent
if found
get the text for the h3 child of cat_bar
set aria-label with the retrieved text
I have reached to put an aria-label to the sceditor textarea:
var ariaEventCount=0;
window.addEventListener('focus', function aria() {
document.querySelectorAll('.cat_bar').forEach(catbar => {
var area = catbar.parentNode.querySelectorAll('textarea');
area.forEach(ar => {
text = catbar.querySelector('h3').textContent.trim();
ar.setAttribute("aria-label",text);
})
})
ariaEventCount++;
if ( ariaEventCount > 2 )
window.removeEventListener('focus', aria);
})
The code is fired 3 time, at this time the page seem to be fully build inclusive the possible editor elements. if if run once this will nor work.
Nothing is done, I have found a way, but I have to modify a lot of things in order to get SMF a little bit accessible. There is always more to do. The event handler is modified in such a way that the right textarea get the aria-label as well as an ID and that the skip links I have foreseen ("go to main content", "go to editor") can be shown. The second link is hidden if not editor present. A further little event handler sent a click event on only clickable elements on keyup. The Theme PHP files are to be modified in order to make clickable and not focusable elements focusable. The help windows need dedicated handling, some more aria-label may be nice, some links may be set not reachable, too many links are annoying.
I also began making the theme nicer from the point of a11y, mainly adding ARIA roles for the elements where it makes sense, mainly for the main content and navigations. Of course, it looks somewhat weird in the admin, as the local menu likely should not be in the main content, but better something than nothing.
@ryrylu
I also began making the theme nicer from the point of a11y, ...
I have also added some aria-label, role may, at some places, be avoided by using accessible HTML5 syntax. You are right the menu for the admin is very weird, Accessibility is usability regardless of the kind of disability (Vision, Cognition, movement disorder, auditory impairments). Usability mean reduce redundant information. For example, within a theme, we have two times a link to the user profile. The navigation (for people which use a screen reader, navigating via the "H" key will see the Name of the user announced as link but not the messages which are more important and will normally shown first by not visual impaired people.
True, the roles could be avoided by using semantic HTML, but as I can not check whether i fixed the stylesheets properly, I did not want to change the structure in any significant ways.
I understood you well, my first intention was to work only with CSS modifications, this seems not to be enough. Since tabindex with value greater as 0 are used, I expect that the different elements will not have the same visually and logically order. Rearranging a little the order within the theme PHP file was the second decision, but at this time I have not done this, there are other things to take into consideration.
@jjsarton or @tyrylu do either (or both) of you have your modified template code uploaded somewhere? Doesn't have to be a repository; a simple zip file will work. I'm curious and want to see your changes.
