Good afternoon!
I propose to add a new HTML/CSS Code style recommendation on our HTML and CSS codestyle page, in the WCAG section:
Properly hide elements:
Hiding visually and semantically:
E.g. an element disappearing from the UI after a user interaction.
CSS: Use the property and value: display: none.
HTML: For inputs only, use the attribute and value: type="hidden".
Hiding visually and showing semantically:
E.g. a label for an interactive element that would just clutter the visual UI.
HTML: Use the class: sr-only. (abbreviation of âscreen reader onlyâ)
Hiding semantically and showing visually:
{{warning}} This technique should only be used on an element that could be removed without changing the user experience in any other way than the presentation.
Example of proper usage: The avatar picture to display a âUserâ entry in a table. Itâs always paired with the name of the user, so itâs not an issue to hide it from assistive technologies. In this case itâs better, since the information is repeated in two elements.
Example of grey area use: A separator in a list. The separator can be seen as nothing but a blank space, but for the user it implies a âseparationâ between two groups of list elements. This separation should be reflected on a semantic meaning, hiding the separator is not the best solution.
Example of a clear misuse: Hiding a picture used to illustrate a <p>. Accessible content is content that conveys the same meaning no matter the technology used to read it. The picture has a purpose and meaning, and hiding this from assistive technologies prevents AT users from getting the full experience.
Use only on leave nodes of the DOM tree because this technique does not hide the content but only the semantics of the node. If you want to hide more than a leaf node, itâs very probable that you should consider hiding it visually too. If itâs still not possible, using the aria-hidden attribute is the last resort.
{{/warning}}
HTML: Use the attribute and value: role="presentation".
Those are obviously not the only possible ways to hide elements, but I figured that if we could be consistent with our practice it would improve code quality. This doesnât cover all situations, but most of them. Some questions should be asked anyways when using other possible techniques.
I decided to prefer role=presentation over aria-hidden. For me, even if the presentation role is a bit less powerful of a , it does not rely on the aria standards but html ones and therefore will have better support and compatibility.
What do you think of this proposal? Is the wording too heavy or imprecise? Is this an appropriate level of detail for a code style convention or should we make it shorter with details in a child page?
Thanks in advance for your feedback
To me this doesnât specify how I would actually hide an HTML element that is not an input and doesnât have a CSS selector to target. Should I use style="display: none"? To me this seems like the worst option of the three equivalent options we have (class="hidden", hidden and style="display: none"). I think I would prefer to use the hidden attribute as it is short and doesnât depend on CSS styles.
I meant it as a way to enforce using CSS for hidden elements, considering that we already have the CSS codestyle:
donât use inline style declarations
Does that make sense to enforce having a CSS selector to target hidden elements?
If you want to make an element hidden visually and semantically using HTML, you can also consider just removing it from the HTML too :))
I know thereâs a fair bit of âpermanently hiddenâ inputs in our source. Iâm pretty sure removing them would spell a lot of trouble, thatâs why I added a mention about them in the proposal.
The label is only mentioned once in an example. The resource you shared is important and should be linked somewhere in the codestyle practice page, but Iâm not sure it would fit in the current proposal.
No, this is important, e.g., for how to hide menus, drawers, ⌠- in most of these cases you want to have them in the source and not add them using, e.g., JavaScript.
Do you mean I should add a new class/id for every element I want to hide and then write new CSS code targeting that selector to hide it? This doesnât sound good to me.
For menus and drawers, in regards to progressive enhancement, they should be showed by default when JS is unactivated. Else, you would lose all the features they contain, which is IMO not a better alternative than a cluttered visual UI.
For most hidden elements, you want to eventually show them using Javascript later on, and to do so AFAIK you need a selector for that too so having a selector doesnât sound bad to me.
Moreover, itâs just the parent element since âdisplay: noneâ (CSS) just like âhiddenâ (HTML) hides every child.
XWiki doesnât use progressive enhancement. It did some time ago but this was dropped.
Yes, true, but JavaScript is more powerful than CSS so you might be able to use something that you cannot use in CSS (yet, CSS is also getting more powerful). Also, Iâm still not convinced that it might not be a good idea in the end to fully hide elements that are referenced by aria-describedby to avoid that screen readers read them twice. And in this case, while you will indeed have an id on this element, it will just create useless CSS code to always also write a CSS rule to hide the element.
Because weâre cluttering the code with a huge number of CSS rules that all do the same.
I think itâs still useful to think with it in mind. Just like accessibility, itâs really difficult to perfectly fulfill it, but keeping it in mind goes a long way.
I wouldnât call it cluttering since I think itâd be less than 5% of rules, and CSS has to be a bit repetitive. The color attribute probably holds more than that and itâs normal⌠But I get your point. I checked it out and bootstrap has a âhiddenâ class with one rule â ''display: none !important". We should probably not use it, since âhiddenâ is just more standard and efficient using HTML or JS.
One point of this codestyle proposal is to limit the amount of ways we use to hide elements, and I thought it would be okay to not hide completely using HTML and favorite using CSS. IMO, we canât remove the CSS way to hide completely (would need JS to expand on hoverâŚ).
Changing the first section to:
Hiding visually and semantically:
E.g. an element disappearing from the UI after a user interaction.
CSS: Use the property and value: display: none.
HTML:
For inputs, use the attribute and value: type="hidden".
This basically means that from now on we should use the hidden HTML attribute instead of a dedicated CSS class, such as class="hidden". Maybe we should state this more clearly. Otherwise +1 on my side.
