Add screen reader class/Less mixin
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Volker_E
	Jul 27 2020, 8:59 PM

Description

Both, MediaWiki and OOUI feature a specific mixin, that is either part of a component or could be a helper class (non-semantic though) to add additional text exposed to screen readers/assistive technology (braille displays as second consumer) only.

MW core:

// Screen Reader Helper Mixin
.mixin-screen-reader-text() {
	display: block;
	position: absolute !important; /* stylelint-disable-line declaration-no-important */
	clip: rect( 1px, 1px, 1px, 1px );
	width: 1px;
	height: 1px;
	margin: -1px;
	border: 0;
	padding: 0;
	overflow: hidden;
}

Similar OOUI

@AnneT has already provided this as part intermediate in https://github.com/wikimedia/wvui/pull/47/commits/8c9101002d057bb9fb893a17e28ae4bbf0052e72#diff-2490260dcd4dbf01664942433ca0a3c5L25, which was then removed from the patch later on.

We need to pick this up and add it.

Open questions

.screen-reader-text() or .visually-hidden()

Staying with `.screen-reader-text

Mixin or class

For componentizing and code modularization reasons we prefer mixins over classes

Resources

Details

	Subject	Repo	Branch	Lines +/-
	styles: Introduce `screen-reader-text()` mixin	design/codex	main	+13 -0

Customize query in gerrit

Event Timeline

Volker_E created this task.Jul 27 2020, 8:59 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 27 2020, 8:59 PM

How do you want to resolve this? This isn't for me to decide but I hope the following will spark progress: Pro / con list? An analysis of the performance in the top screen readers? Some other acceptance criteria?

It looked like you had already identified one concern with a class-based approach: non-semantic. Perhaps the argument for class-based is better bandwidth use (but maybe this is less impactful with compression). Has OOUI had any shortocmings with the mixin approach that would help inform?

Some loosely related discourse on screen reader components.

Volker_E claimed this task.Aug 10 2020, 5:17 PM

Using a mixin duplicates the rules at each use site. With 9 rules that creates unnecessary bloat. A normal CSS class is better for this purpose, wordpress has .screen-reader-text, that's fairly widely understood and common.
However to address Volker's disapproval of a single utility class the rule can be made with an attribute selector as done in this commit:
<span screen-reader-text> Audible, but not visible text </span>, that's similar to and consistent with the CSS standard
<span hidden> Content not displayed </span>

Answers:

.screen-reader-text (popularized by WordPress), or .screen-reader for conciseness.
class (common) or attribute (consistent, sound)

Question
Is there a practical need for this complex hiding? top: -9999px; is a simple solution that has been in use for hiding the Navigation landmark's heading for years without complaint (git). The complex solution also covers some fringe scenarios that's questionably necessary.

.screen-reader-text {
	position: absolute;
	top: -9999px;
}

There's beauty in simplicity.

• Demian updated the task description. (Show Details)Nov 6 2020, 12:21 PM

Volker_E moved this task from Requests to Review to Wikimedia Vue UI (WVUI) on the Design-Systems-team-20200324-20220422 board.Feb 1 2021, 4:39 PM

To provide some extra context here on comment above,

gzip is taking good care of such repetitive code blocks
it could be considered to have a Less mixin call that outputs several callers in a combined selector

In contrast a repetitive class, specifically in different contexts isn't necessarily best-possibly gzipped, leading to more code sent to the client.

To the second point of absolute positioning, this works with navigation landmarks on the page, as they have relative fixed positions in the page layout. With a library's components it could end up that you output component at the end of a real long article (ex Barack Obama) and the absolute positioned text is visible at top of the article as side-effect. Therefore the slightly more complex absolute positioned and clipped text is preferable.