‘Special Characters’ Accessibility and Usability

☰ Navigate this post:

• Introduction
• The Problem
• Missed Opportunity
• Experiments
• Testing Solutions
• Solution when all else is impossible
• Summary
• Reference this post

Introduction

I’m concerned when we expect screen reader users to overcome our design and technology shortcomings. Why should they ‘work around’ barriers we create? When they learn a ‘workaround’ that becomes a global strategy, that should not prevent our solving the core reason for it.

We should design to solve these usability issues as well as aim for only accessible. It’s the premise of inclusive design, after all. We may not have perfection and we can surely make best of what we have.

The Problem

In form validations—notably password inputs—and within long passages or tables of API data-value pair validation rules, we often refer to the type of characters allowed in a field. For example:

Must contain only A-z [SPACE] . {} = , ‘ : ^

Screen readers do not announce every piece of punctuation. Screen reader users can adjust settings to increase verbosity and read more punctuation, or step through individual characters. So, we can leave the characters typed as they are. Yet that’s surely a ‘workaround’ when we expect our non-visual users to find a way to interpret or cognate what we have presented.

Equitable Experience

Make no mistake, presenting the characters like this is a visual design strategy. There is no reason we cannot write the punctuation names in full prose. For example:

Alphabetic characters, numbers, period, commas

The common visual design is to present the actual characters to aid and enable recognition: a direct visual-cognitive link between the shape of the character and its keyboard key. It makes so much sense for the visual experience and saves an amount of translation too. The point is, its a visual strategy. It may also be a Braille strategy?

From a screen reader user’s perspective, the punctuation has a name and not a shape. We want the punctuation to be announced and we want it announced meaningfully. That means reading out the name of the characters and not the symbol.

I explored the concept. Common thinking is that screen reader users will cope with the punctuation in context and adapt their screen reader technique to read the punctuation. Fine. And it’s still not an equitable experience? It’s simply more work than visual users do in looking, recognising, and remembering.

“Personally, if it’s clear I’m reading punctuation, and it’s important to know what exact punctuation, then I’d use read-by-word to navigate to the cluster, then read-by-character to read each character. It might be possible to arrange the HTML and aria such that Jaws automatically reads what you want, but if I’m trying to learn the syntax, I’ll likely read by character just so I can go at my own pace.”

Potential Barriers

The problem with Ted’s use case is when we write something like the following:

A-Z 0-9

The characters are A Z 0 9 and two hyphens. Not, “Letter A to Z and numbers 0 to 9”. Even then, “numbers zero two nine” opens a risk, no matter how unlikely. We cannot depend on the accuracy of our users’ comprehension, language, or wakefulness. We should design for all scenarios if we are to be truly inclusive.

Scenarios include people with visual impairments who require the characters to display responsively, or be enabled to zoom in on them in the browser when necessary. This is vitally important when we include micro-scaled punctuation such as periods, commas, and apostrophes (or single speech marks or single quotes).

Missed Opportunity

Shane commented on my post on a Facebook a11y group discussing the special character problem:

“i think screen readers should have [been given] an increased verbosity setting for the code element or role.”

I have to agree. At first I thought the problem could still remain that, when listing to an array of special characters in the code for copy text and including punctuation screen readers do not by habit announce, those characters could still be omitted from the announcement? On reflection, as a programmer who is blind, you’d want every character announced that isn’t a letter or numeral forming a word or number? That and indent levels for YAML, I guess.

Shane makes a great point. A ‘verbose’ screen reader announcement of the code and pre elements could solve this problem fully?

Testing Solutions

The following are experiments to determine a recommended strategy to present special characters when intended read.

There are two recommendations made that account for our use of Content Management Systems that can be so backward that we cannot write semantic HTML or custom CSS to them. Each recommendation presents the array of characters or each individual character as an image with accessible text.

What echos between my ears is Ted’s point about pace. Could announcing the characters in one long soliloquy exceed our capacity to comprehend, process, and cognate the rules compared to approaching each character in turn? As with anything in design it seems this problem’s solutions depends. It depends on our users.

Caveat User Testing

I would dearly love to test a group of blind developers to garner their opinion and also a group of less experienced screen reader users who have not learned to overcome barriers with strategies amounting to workarounds. It’d be useful, illuminating, and I would hope conclusive. I cannot pretend to be blind. Without input from people who are blind, I can only empathise and do my best to avoid do-gooder hubris. 

” Blind programmer checking-in…They then write up their experience…present their work as ‘I found this hard, so all blind people must find this hard.’ Identifying when a task has a large learning curve is important, but also do keep in mind that people who are blind have significant experience in identifying ways to overcome potential accessibility problems.”

Read on. Try using your operating system’s screen reader to listen to the audible experience of each test case.

Experiments

No special treatments

The following have no special a11y treatments or CSS styles applied and sit within a div. They are separated by spaces. This replicates the only text-based strategy available on our instance of Drupal.

<p>Valid characters include: A-z [SPACE] . {} = , ' : ^</p>

Images

The following example uses image alternative (alt) texts as the accessible text. The image links are broken so the alt displays. The images are each of the relevant punctuation and given a small margin to their right using CSS.

<h3>One character to one image</h3>
<img src="none.png" alt="Alphabetic characters"><img src="none.png" alt="Periods"><img src="none.png" alt="Spaces">
<h3>One or more characters to one image</h3>
<img src="none.png" alt="all alphabetic characters, numbers, space, period, curly brackets, equals sign, comma, apostrophe or single speech mark, colon, and caret">

Using the kbd element

The kbd element seemed a logical choice and of course, fails to offer the correct semantic where the validations do not all represent a real key press. It is also read as a group.

<kbd>A-z</kbd><kbd>SPACE</kbd><kbd>.</kbd><kbd>{}</kbd><kbd>=</kbd><kbd>,</kbd><kbd>'</kbd><kbd>:</kbd><kbd>^</kbd>

Replacing the kbd element with a styled span

Although clunky, the span enables VoiceOver to read the punctuation and us to add a visual style as we choose.

<span class="kbd">A-z</span><span class="kbd">SPACE</span><span class="kbd">.</span><span class="kbd">{}</span><span class="kbd">=</span><span class="kbd">,</span><span class="kbd">'</span><span class="kbd">:</span><span class="kbd">^</span>

(Recommended) Adding ARIA. Does it make a difference?

Adding role="img" and aria-label="" should give screen readers precise instructions not to read the span content.

<span class="kbd" role="img" aria-label="alphabetic characters">A-z</span>
<span class="kbd" role="img" aria-label="space key">SPACE</span>
<span class="kbd" role="img" aria-label="period">.</span>
<span class="kbd" role="img" aria-label="curly brackets">{}</span>
<span class="kbd" role="img" aria-label="equals sign">=</span>
<span class="kbd" role="img" aria-label="comma">,</span>
<span class="kbd" role="img" aria-label="apostrophe, or single speech mark">'</span>
<span class="kbd" role="img" aria-label="colon">:</span>
<span class="kbd" role="img" aria-label="caret">^</span>

(Recommended) A Single Span Instance

A single span may be an improved experience when in an instructional text. For example:

<p>Valid characters include, <span class="array" role="img" aria-label="all alphabetic characters, numbers, space, period, curly brackets, equals sign, comma, apostrophe or single speech mark, colon, and caret">A-z 0-9 SPACE . {} = , ' : ^</span>.</p>

Using a list

Logically, a screen reader user will not know how many items are listed in an array of punctuation. Placing the items in a formal unordered or ordered list may help?

<div class="container">
<ul class="no-list-style">
<li><span class="kbd" role="img" aria-label="alphabetic characters">A-z</span></li>
<li><span class="kbd" role="img" aria-label="spaces">SPACE</span></li>
<li><span class="kbd" role="img" aria-label="period">.</span></li>
<li><span class="kbd" role="img" aria-label="curly brackets">{}</span></li>
<li><span class="kbd" role="img" aria-label="equals sign">=</span></li>
<li><span class="kbd" role="img" aria-label="comma">,</span></li>
<li><span class="kbd" role="img" aria-label="apostrophe or single speech mark">'</span></li>
<li><span class="kbd" role="img" aria-label="colon">:</span></li>
<li><span class="kbd" role="img" aria-label="caret">^</span></li>
</ul>
</div>

Solution when all else is impossible

Using a platform that negates ARIA attributes and where alternative text seem a clumsy experience for people using screen readers, the solution appears to be improved writing?

In conceptual testing the grouping of the valid characters in a single cell failed to solve the problems we originally identified. To a screen reader words are words, letters are letters, numbers are numerals, and punctuation is punctuation.

In the following table, we have written full descriptions of character groups and then the special characters. The intention is improve the experience for people using screen readers. The strategy may require cognitive effort to divide the long descriptions from the special characters. Some special characters may not be announced without the screen reader verbosity being adjusted at the key moment.

In the following table, the single valid character column is split in two:

1. Letters and Digits
2. Special Characters

The objective is to enable people using screen readers to adjust the verbosity on exact cue when entering the Special Characters cell.

You may claim the following?

• Visual users now have more to read.
• There is an increased cognitive load.
• The strategy demands more real-estate.
• Copy texts are the enemy of simple design.

Where so I would urge you to:

• Consider the ableism loaded in each statement.
• Recall we design for our users and not for our beautiful portfolios.
• Inclusive design equalises the experience for everyone.

Currently Best Solution

For the limited CMS environment, I think the best solution is to:

• Offer visual users images to aid recognition
• Offer screen reader users long texts

My hope is that screen reader users may still read the copy text word-by-word if pace is important to them. Meanwhile, by giving the images an empty alternative attribute, they will not be bothered by the screen reader’s repeated reading of “image” or “graphic”, etc.

It’s a compromise solution. The following figure illustrates an example (with deliberately missing images.

The images used in the following table have empty alternative attributes and are used for demonstration purposes only.

Data Validation Rules

Data	Valid Characters	Example
Input 1	Letters and accents, digits, spaces, percentage, carets, ampersands, semi-colons, asterisks, and left and right parentheses	My( )1Npú7
Input 2	Capital letters and underscores	INPUT_TWO
Input 3	Digits from 0 to 99, minus, plus, forward slash, equals, and asterisks	49*2=98

Residual Questions

I really need to access someone with the expertise and attitude to help form a usable strategy for both visual and non-visual readers. I’ve posted the following questions to my favourite Facebook group for professional workers in our field:

3 accessibility questions occur when including blind software developers in writing API documentation in HTML where ARIA or other screen-reader only texts are not available to the CMS.

1. Can a blind developer identify the letter case of JSON key names? For example, “TxSyKey”, where the T, S, and T are capitalised. If not, how can we help?
2. When discovering data validation rules in an online document’s tables, is it helpful to present two columns; one for letters, digits, and spaces; and the other for special characters? For example, a Standard Character column may include the words, “letters and accents, digits, and spaces” where the Special Character column would contain valid punctuation and symbols. The intention is to remove confusions the following visual strategy may introduce: A-z á 0-9 – & space .
3. When presenting example values in a column such as TRUE and FALSE, should they be inline or in an unordered list?

I value the responses there or in your comments to this post.

Summary

We can abandon people using screen readers to their own experience of data validation rules. It seems our industry does just that and people using screen readers have learned to adapt to what is clearly the normal (ableist) experience.

I cannot sit with that. There are visual design patterns enough that are accessible and deliver a poor inclusive experience. Stripping back to clear writing may, or may not be the solution in your platform. What you design will depend on your environment, users, and testing.

As a backstop, and certainly while writing to an inflexible and restrictive CMS, the solution is to improve our writing and offer an inclusive experience.

Add the ability to employ ARIA on your platform and things can only get easier for everyone—when your designers and writers are enabled to write it.

Accessible Writing Notes

• Numbers are a concept.
• Numerals are symbols for numbers. For example, IV, ٤, and 4.
• Digits are the number numerals 0 to 9 in English.
• A letter is any symbol for a sound in an alphabet.
• Alphabet does not necessarily equal “A to Z”. English alphabet does.

Setting specific local context for internationalisation may be important. For example, when exporting a platform from the United Kingdom to Israel, Greece, or Turkey and maintaining the English alphabet and digits.

Reference this post

Godfrey, P. (Year, Month Day). Title. Retrieved , from,

Top