I meet often the following problems in the Accessibility Checker.
- Replace your i elements with em or strong. (mainly in the sub-menu, list element, text element)
- Add a fieldset and legend element to the form for each group of radio buttons. (form element)
Is there any possibility to solve these problems?
Welcome to the forum, and thanks for reaching out!
Which tool are you using for the tests?
- The i elements are probably the submenu indicator icons, right? In that case, neither em nor strong make more semantic sense.
- We can certainly adjust the markup when we get a chance (same goes for checkbox and select). I will consult with the team.
Thank you for the contact.
The main tool that i use is AChecker Web Accessibility Checker
and secondary the wave[dot]webaim[dot]org
Both, but primarily the first tool is also used for certification by government agencies.
The Rationale for i element is that the i element is not handled as well by screen readers as the em and strong elements.
Details about the element are here: https://achecker.achecks.ca/checker/suggestion.php?id=117
Details about the form markup you can find here:
Icons really shouldn’t be wrapped in i tags - even fontawesome explains in their documentation that despite it being the default, it’s the wrong way to do it.
Well, however, they do not stick to it. Every single icon on the fontawesome site is using the
<i> tag @Pete
Again, replacing the
<strong>, as the accessibility check suggests, doesn’t make any sense in terms of semantics because the icon isn’t either emphasized or strong text. The only element that even comes close is
Nonetheless, this is a massive change that should be well thought out and not rushed. One thing at a time…
Correct, but they say in their own documentation that this is incorrect implementation and you should not do it this way
then i would call this a concerning response from bricks. we really need accessibility solved in a professional way.
Correct. Accessibility is getting more and more important these days. Fully agree!