Accessibility

[jjsarton]

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

[sbulen]

Connecting up the forum topic:
https://www.simplemachines.org/community/index.php?topic=584355.0

[jjsarton]

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.

[Sesquipedalian]

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:

1. 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.

2. 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.

[sbulen]

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.

[jdarwood007]

Do these fail using Chrome's Lighthouse check or is there another tool to assist us here?

[Sesquipedalian]

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.

[jjsarton]

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

[jjsarton]

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.

[jjsarton]

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.

[jjsarton]

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

[jjsarton]

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.

[albertlast]

what is the definition of done in this issue?

[jjsarton]

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.

[tyrylu]

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.