What’s in a label? Developing accessible software with ARIA labels and alt-text

We take a look at a web developer’s implementation considerations with alt-text and ARIA labels and explain how we developed SpokenMath, our custom software for accessibility.

When building an education product for the web, accessibility is an increasingly important consideration for every conscientious product designer and developer. In this article, we’ll explore the main focus points of accessibility for Learnosity applications and share some lessons from our implementation journey.

Accessibility is a government requirement

New government mandates (such as Section 508 Amendment to the Rehabilitation Act of 1973, in the United States) require that public sites and applications from federal agencies offer accessible functionality for users with different levels of ability.

Since 2015, organizations that do not comply face stiff penalties. Other jurisdictions around the world are following suit. Considering that nearly all education is directly or indirectly funded by government agencies, this shifts accessibility as a product characteristic from the “nice-to-have” column into the “must-have” column.

Accessibility as a product characteristic has shifted from the “nice-to-have” column into the “must-have” column. Share on X

Learnosity users who need accessibility features face a variety of challenges such as visual, auditory, motor/mobility, and cognitive/intellectual impairments. By aligning with web accessibility standards, we can develop software that serves all of our potential users, no matter what their ability range may be.

Developing for accessibility in an agile environment

At Learnosity, we’ve put considerable time and effort into getting our accessibility right from a technical point of view. Starting with the aim of supporting web accessibility standards (WCAG AA), our development team has adopted a pattern of focusing on each Question type, evaluating and testing its accessibility, improving it, and then reviewing it again down the line.

Our developers have adopted a pattern of focusing on each Question type, evaluating and testing its accessibility, improving it, and then reviewing it again down the line. Share on X

These accessibility iterations help steadily move our products toward complete support for accessibility standards (as well as maintain that support over time). All of this affords developers that use Learnosity the capacity to build high-quality educational software that will deliver a genuinely accessible experience.

Along the way, we’ve learned a thing or two about developing software interfaces for accessibility. So here are a few nuggets of advice we’ve gleaned from our experiences.

Adding alt-text to images can make information more readily available

Alternative text, or “alt-text”, is a way of providing text as a communication alternative for web page images. Alt-text exists primarily to offer visually impaired users information about an image on screen.

For accessibility users, the alt-text will be either spoken by their screen reader software or processed by text-to-braille systems. There are several cases worth bearing in mind when supplying alt-text:

1. For imagery that provides essential information – for example in a chart graphic – provide alt-text that gives the user the key information that other readers would gain from viewing that image. For example, alt-text for a line chart might explain: “The quantity of nitrogen absorbed in the soil was increased by five percent during this experiment”.
2. If any informative text is baked into an image, you must provide it in the alt-text or it will be unavailable to visually impaired users. Text-as-imagery is a pattern that should be avoided in an educational context for exactly this reason.
3. For imagery that is used to set the stage for your message (such as photos), a short description may help orient the reader. For example, in a political context, a photo of two world leaders shaking hands at an important moment in history ought to have an alt-text description to make that information available to the user.
4. For imagery that does not provide essential information, such as icons or other strictly decorative embellishments, you should provide an alt-text of null (alt=””) so that the screen reader can skip them. This is because in the screen reader context, these extra elements only add noise to the signal that the user is trying to process.
5. Note that supplying a null value for alt-text is not the same as providing nothing at all – without alt-text, screen readers may automatically do things like read out the filename of every graphic file on the screen. Needless to say, this creates a less-than-ideal experience for the user.
6. Alt-text is also handy for all users when they are in a degraded Internet environment (i.e. a slow connection where only the text content will load) as alt-text will appear in place of the image if it is not available or cannot be rendered. This lets users grasp the essential message and still interact with the page, despite the lack of imagery.
7. Alt-text should not be too long. The rule is of thumb is to generally stay under 120–150 characters. Because ARIA labels are simply ‘read’ by the screen reader, the user has no ability to use the usual reading mode functionality in screen readers for navigation such as pausing, moving backward and forward in the text, reading word by word and so on. All they can do is skip the label, so if it’s too long and verbose, the user may skip it and miss important details. 

Learnosity allows for alt-text entry in its authoring environment, wherever images can be added to content.

Adding ARIA labels for accessible interaction

ARIA labels are essential in allowing visually impaired users to navigate your interface and multimedia controls in a screen reader context. They can also assist users who cannot operate a mouse. ARIA labels are defined in the Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) specification.

At Learnosity, we are mindfully adding ARIA labels to things that users can interact with, such as video players.

We also apply them to interface elements, and other categories mentioned in the definition. When applying ARIA labels, we take automation approach at Learnosity: the ARIA labels for all interactive elements are automatically inserted by our system wherever they are required.

The Learnosity authoring interface offers many entry points for customizing the ARIA label for inputs and elements, while also offering the ability to “label bundle” all ARIA labels we have in the product. It offers our clients the ability to both customize the ARIA labels to their needs, and complete control of accessibility and internationalization.

When developing on the Learnosity platform our system will generally handle ARIA labels for you. Share on X

The great thing about this is that when developing on the Learnosity platform, you get the benefit of this automation as our system will generally handle ARIA labels for you. This is because every Learnosity Question type injects ARIA information into the DOM automatically, where required.

Math that speaks – creating custom software for greater accessibility

Sometimes, the open-standards for accessibility don’t cover the things you are creating. We discovered this for ourselves when we came across an accessibility problem unique to the educational sphere.

We use the LaTeX typesetting system to capture the math that users create in our dynamic math entry system. We wanted to offer accessibility to visually impaired end users when they are entering dynamic math, but there was no tools or technology that could do this.

Pre-supplied math equations (in the question stimulus, for example) could be spoken by screen readers (the Assistive MathML generated by the static math renderer). But when the user starts to write their answer for a math question, they need to have their entry spoken back to them to ensure it is the answer they wanted. There was no such system available to read and speak the math entry, as it would require additional code to dynamically process the LaTeX math, right when the students are typing it in.

We began developing some custom accessibility technology to bridge the gap. This involved creating an automatic parser for the math content (in LaTeX format), converting this into a descriptive text string, and then injecting this back into the page (DOM) as an ARIA label.

Learnosity developed a custom accessibility software to allow visually impaired users listen to their own responses as they type. We call it SpokenMath. Share on X

The end result is quite effective and allows an end-to-end accessible experience for visually impaired users to hear the math question (spoken by the screen reader), navigate the math interface to construct their answer, hear their answer read back to them, then submit it. For example, for a fraction such as “2/4”, the LaTeX for this is ‘frac{2}{4}’, then the spoken text output is “fraction, 2 over 4”.

We call this feature SpokenMath.

Video: The dynamic text output for screen reader software that is generated by the unique SpokenMath component.

There is an option to utilize SpokenMath for all static math, which offers authors the ability to override the SpokenMath output. For example, if you have a different word for some math elements in your culture or locale (as is frequently the case), then you can enter your preferred word to make it more familiar for your students.

When using Learnosity to deliver a math education product, you automatically receive the benefits of SpokenMath, dozens of pre-built Question types, and built-in accessibility compliance. Share on X

Hopefully, this piece has given you some ideas about how you can go about developing for accessibility in your web application. We’ve discussed our agile approach to accessibility, considerations for alt-text and ARIA labels, and when to write extra code to fill gaps in the accessible experience. Armed with this knowledge, you too can create software that works for everyone.