‘Special Characters’ Accessibility and Usability

image sprite of special characters in a dark and a light theme Reading Time: 9 minutes

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

Ted on a Facebook A11y group today.

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.

No special treatments

Valid characters include: A-z [SPACE] . {} = , ‘ : ^

Result

It reads as follows: “A Z Space Left curly bracket, Right curly bracket, Equals, Caret”. The relationship between the A and Z is lost and the period, comma, apostrophe, and colon ignored.

When approached character by character, the hyphen is announced. The hyphen is not a valid character in this rule set. Likewise, the addition of square brackets around “SPACE” was an incidental nod to visual design. If the square brackets are announced, then another invalid character is added to the naughty list of errors.

HTML

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

Images with alternative text attributes

One character to one image

Alphabetic charactersPeriodsSpaces

One or more characters to one image

all alphabetic characters, numbers, space, period, curly brackets, equals sign, comma, apostrophe or single speech mark, colon, and caret

Result

The individual images in the array read as follows: “Alphabetic characters, image. Periods, image. Spaces, image”. Although the output is accurate, the inclusion of the repeated “image” adds an additional cognitive cost to the experience.

The combined array within one image reads: “all alphabetic characters, numbers, space, period, curly brackets, equals sign, comma, apostrophe or single speech mark, colon, and caret, image”. It is an improvement listening experience. How many is too many though—for cognition and the alt string length?

Notes:

  • In Safari and with default styling, the alt content overflows its container.
  • Combining the span strategy with CSS text-displacement with image sprites is an alternative use of images.

HTML

<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">

Example Image Sprite

image sprite of special characters in a dark and a light theme

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.

Enclosing punctuation within keyboard (kbd) elements
A-zSPACE.{}=,':^

Result

The kbd contents are pronounced. The A-z is read as, “A Z”, which does not have the same semantic as, “A to Z” or indicate the use of upper and lower cases. Additional accessible text is required. The - may also be interpreted as valid when invalid.

HTML

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

Using span elements
A-zSPACE.{}=,:^

Result

This works OK and is hit-and-miss on what gets announced depending on the VoiceOver setting used. An immediate advantage of course, is that as with the kbd strategy, when the visually presented keyboard keys are copied and pasted into a document, they paste cleanly as characters. (For example, A-zSPACE.{}=,‘:^). It’s good to know spaces are required when this is a deliberate use case, and should probably be added in any use case?

HTML

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

Adding ARIA to span elements
A-zSPACE.{}=,:^

Result

Output is as expected. VoiceOver reads the accessible label content, ignores the span contents, and appends the role, “image”.

HTML

<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:

Adding ARIA to individual span elements

Valid characters include, A-z 0-9 SPACE . {} = , ‘ : ^.

HTML

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

Result

This works so well, I’d use it in preference. With the right font, the micro-sized punctuation should be discernible to people with visual impairments using their own ABT. As responsive HTML font, the character array can be zoomed or increases in size without breaking anything.

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?

Using a list
  • A-z
  • SPACE
  • .
  • {}
  • =
  • ,
  • :
  • ^

Results

No advantage.

HTML

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

Writing fuller descriptions
Data Validation Rules
Data Valid Letters and Numerals Example
Input 1 Letters A to Z, Accented letters, Numbers 0 to 9, Spaces and %^&*() My 1Npú7
Input 2 Capital letters A to Z and _ INPUT_TWO
Input 3 Numbers 0 to 99 and -+/=* 49*2=98

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

  1. Letters and Numerals
  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.
Dividing free text from special characters
Data Validation Rules
Data Valid Letters and Numerals Special Characters Example
Input 1 Letters A to Z, Accented letters, Numbers 0 to 9, and Spaces %^&*() My 1Npú7
Input 2 Capital letters A to Z _ INPUT_TWO
Input 3 Numbers 0 to 99 -+/=* 49*2=98

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.

Reference this post

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

Top

 

Leave a Reply