Invisible Accessibility: Text Alternatives and Captions


Computer-based devices are ubiquitous in our daily lives and most people interact with a computer interface with some regularity. But people are unique and people’s capabilities are different, and vision, hearing, and mobility disabilities are not uncommon. People with hearing and vision disabilities require alternatives for text and multimedia, and people with fine motor control disabilities need interfaces that respond to screen readers, voice commands, and other input methods. This post examines some best practices for making sure an interface is accessible to all.

Text Alternatives

Text alternatives are text-based equivalents for non-text objects in an interface. Think of little bits of descriptive text embedded in the HTML of images, buttons, and other elements of an interface. By adding text alternatives to buttons and other interactive parts of an interface, a person with vision or motor control disabilities will have an easier time navigating the interface through the use of screen readers and other assistive technologies. These text alternatives are not always visible for the end-user and that’s by design. They are typically encoded into the HTML that powers an interface and designed to be machine-readable, so applications such as screen readers or braille devices can interpret the text alternative for users with vision disabilities and present that information to the user. Without text alternatives coded into the interface, a blind user cannot navigate that interface. Encoding text alternatives for buttons allows for voice controls, keyboard control, or other assistive devices to interact with the interface, helping users who have movement difficulties.

a screenshot showing a screen reader reading the alternative text on an image

The image above shows a screen reader reading the alternative text for the cat photo on the right side of the screen, with the screen reader’s voice over appearing in the black bar at the bottom. The HTML associated with this cat photo includes not only the image file name but also an “alt” attribute with the text the screen reader reads. While this is a simple example, the same general concept applies for all forms of text alternatives. However, not all aspects of an interface use text alternatives as an accessibility method. In multimedia elements of an interface, additional methods are needed.

Captioning and Audio Descriptions

While text alternatives are great for helping make interfaces themselves accessible, multimedia (video, audio, e.g.) elements of an interface require special solutions for users with disabilities. A deaf person with fine vision will have no problems with normal interfaces (unless they use audio cues to communicate), but video and audio files associated with the interface can present challenges. This is where captioning comes in.

An example of closed captioning at work

There are two forms of captioning, closed and subtitling (technically there is a third, open captioning, where content is captioned for spoken language all the time and not only when requested by a machine or user). Closed captioning is used to describe the entire significant auditory landscape of a piece of media to a deaf or hard-of-hearing user. This can include dialog, emotions, or important auditory or musical moments. Subtitling is slightly different and assumes the user can hear but not understand the language being spoken. Note, only the US and Canada really distinguish between captioning and subtitling. Like text alternatives, captioning should be included in all multimedia that is used in an interface to aid people with disabilities. Audio descriptions are similar to captioning (and text alternatives) in that they provide an additional method to experience a piece of content, but in this case they serve to aid people who are hard-of-sight by describing important visual details in a video.


There is no one-size-fits-all solution for accessibility options for interfaces, but there are tools available to developers and content creators to ensure their work is accessible to the most people possible. Including text alternatives for every element of an interface during the development process will go a long way to ensuring an interface’s accessibility, and it doesn’t require a large amount of extra work for developers. Content creators have a similar need to supply captions or auditory descriptions with their work. Captioning is a time consuming and/or expensive process to get right, but including captions allows a broader range of people to consume the content.



Design Critique: Dark Sky (iPhone app)

Dark Sky’s initial view upon opening the app. Note: the author has blurred the address at the top to protect his privacy


Dark Sky is a hyperlocal weather application for mobile devices, notable for its accurate predictions of upcoming weather at your exact location. Dark Sky also includes a 7-day general forecast and a weather map that scales from global to local, showing radar data over a timescale that varies based on the scale of the map.

The Forecast Page

The forecast page, shown above, is what the user first sees upon opening the app. The current conditions at the users location is displayed in large lettering at the top, with a map preview just below. Further down from the map is an hourly forecast and written description of the weather for the day. The map is clickable, and takes you to the map screen. While the map preview is lacking any obvious signifiers that it is clickable, the designers of Dark Sky have relied upon cultural conventions associated with weather apps, and mobile app design in general, and embraced the perceived affordance that touching the preview at the top will enlarge the map.

Dark Sky’s map screen. The timeline at the bottom changes to represent hours once you zoom into a specific locality, though there is no signifier this will happen.


A sticky toolbar is also included at the bottom of the screen, remaining in place whether scrolling or changing modes. The toolbar is an expected design feature, common to mobile applications, and the icons provide good discoverability for what other major actions are possible in the application (the same holds true for the search and settings icons at the top).

Further Down The Forecast Page

While not immediately discoverable, the forecast page of Dark Sky is actually quite long and there is more information hidden below the fold than immediately available to the user. The only visual signifier that there might be more below the bottom edge of the screen is a small part of the hourly forecast seems to run off the screen, hiding behind the toolbar. Conventions relating to the use of mobile applications probably result in users attempting to scroll anyways, but there is a small issue here. An easy fix would be to add an indicator on the left side of the screen, a vertical 3-dot indicator or a scroll bar would suffice.

Dark Sky app once the user has scrolled down on the forecast page, showing the hourly forecast as well as the 7 day forecast.

There’s another issue here below the fold that becomes obvious once the user scrolls. The red buttons under the hourly forecast are lacking strong enough signifiers to make them obvious as buttons that modify the hourly forecast. A solution would be to move these interactions above the hourly forecast, so that they feel like data filters. In addition to the bolding applied to the active button, graying out the non-selected options will help signify that they are indeed buttons to be interacted with.

Mockup showing a potential solution for the hourly forecast filter buttons issue. Buttons have been moved to the top of the hourly forecast, and only the active filter is red and bold.

The 7 Day Forecast

Below the hourly forecast, Dark Sky presents a 7 day forecast with low and high temperatures presented in a graphical representation. Each day is expandable to an hourly forecast, but this interaction lacks any signifiers that the user can expand to a more detailed view.

7 day forecast view.

While some users may have a conceptual model that it should be possible to click on the individual days to drill down into a more detailed view, the lack of signifiers can result in lots of users missing functionality of the app. A simple fix would be to add slim down-arrows into the temperature-range bar (or elsewhere, aligned with each day), implying that there is an action to take for each day in the 7 day forecast.

Mockup showing the addition of down-arrow signifiers to the 7 day forecast, and the hourly forecast for the day after a user has clicked.


Dark Sky is a powerful and feature rich weather application, and with a minor amount of adjustment some of the issues in it’s design around discoverability and the gulf of execution could be easily rectified.