There are so many reasons why YOU (and your student!) should know how to check the accessibility of an app with a screen reader. Here are a few of the most common reasons:
- You just found out that your student’s class is going to use a new app and you need to preview the app to see if it is accessible.
- Your student did not complete his/her assignment and stated that the app was not accessible.
- You have been asked to explain to your school’s administration and/or IT department why your student needs access to a different app than his/her peers.
- You want to report to the developer that something is not accessible.
While this post will specifically look at iOS app accessibility, the same thought process applies to any device and any screen reader.
First, confirm that you are using the most current version of iOS – unless you know there is a critical bug in the latest version, or a big update was recently pushed out. Often updates after the big yearly update will resolve bugs. Also be sure that you are using the latest version of the app itself. You do need to know which iOS version you are using and the app version to report a bug to the developer.
Most common inaccessibility issues with educational apps designed for young students
Inaccessible Graphics
There are many educational apps designed for young students which are very visual. Many of these apps are not accessible with VoiceOver, as the screen is a graphic – VoiceOver cannot read images, only image descriptions/alt text. How do you know if the screen is displaying a graphic? With VoiceOver on, open the app. Drag your finger around the app. Does VoiceOver announce what is visually on the screen? Or do you only hear, the “thunk, thunk, thunk” earcon that indicates nothing is there?
Right Swipe. Does VoiceOver announce anything? Left Swipe. Does VoiceOver announce anything? If nothing is announced, that means that the screen is not accessible with VoiceOver. Often when you right or left swipe on an inaccessible app, you will hear a deeper “thunk” sound that indicates you have swiped and hit the wall – or you were on the last item and swiped again and nothing is there. Some apps may be partially accessible, meaning VoiceOver will announce something, but it does not announce everything on the page.
Images without image Descriptions/Alt Text
When you drag your finger over an image (or swipe to navigate Voiceover to the image), VoiceOver will read the image description if one is available. Typically VoiceOver will also announce “image”. Remember, the app developer had to add the image description; the image is not accessible without the image description. Sometimes the image will be announced as a string of numbers and then the word “image”; this does alert users that there is an image, but without an image description, the user has no idea what image is there. With educational apps, not labeling the image frequently means that the student cannot complete the activity.
Note: With many math apps, the developer will choose to use an image of a fraction, math symbol or equation and not an actual typed-out symbol. If the math symbol is a picture, it not accessible – especially if the student uses a braille display!
Buttons Not Labeled
Buttons are areas that you can select, such as the Back button or Settings button. VoiceOver should announce the name of the button first followed by the word, “button”. Example: “Settings, button”. When you hear the word “button”, you know that you can activate it. To be accessible, both the correct label and the word “button” should be announced.
Many mainstream apps designed for toddlers and preschoolers (very simple touch anywhere on the screen and something happens, are self-voicing. However, the Play Button is not labeled or cannot be activated with VoiceOver on, so the student cannot even start the app! Keep in mind that there are TVIs and family members who are also blind or low vision and need all the buttons – including the settings options – to be accessible.
Note: If you have a new bug in an app that previously did not have that bug, do an Internet search and see if others have this same bug and if there is a work around. You can also check with colleagues and other resources, such as Paths to Technology.
Predictable Layout
Ideally, the app layout mirrors the standard layout with the tool bar at the top of the page with the Back button in the top left. This makes it easy for students with visual impairments to be able to find the tool bar. There are also additional VoiceOver commands to jump to the first item on the screen (first item is typically the Back button) and to jump to the last item on the screen (last item is typically the Next Page button).
Apps that have moving graphics (like the animated fish in the app above) are often not accessible and if they are accessible, it is challenging for a student with visual impairments to find a moving target. In the example of the Hungry Fish app, the student has to find the moving bubble numbers, drag one moving number on top of another moving number, then drag the numbers to the moving fish.
The exception to this is self-voicing toddler apps such as the bubble apps, where toddlers can randomly tap the screen with multiple fingers (vision not required) and pop the bubbles.
Movement on Screen
It is also important that if there is movement on the screen that is important, that the movement is verbalized or indicated in some manner. With mainstream educational apps for young students, often the directions are given visually with an arrow tapping or dragging an item. Detailed verbal descriptions should be included for students with visual impairments.
Another example of critical movement on the screen is with coding concept apps. Many basic coding concept apps include simple coding (arrows or drag-and-drop code blocks) with the goal of making the robot or character move – a visual only action. So even if the coding portion of the app is accessible, the student with visual impairments has no way of knowing if he/she coded correctly.
The CodeQuest app, a coding concept app, has made the maze accessible, as each block in the maze is announced with VoiceOver. The directional arrows each have an assigned auditory sound and as the character moves, that sound is heard. CodeQuest is a great example of an accessible coding concept app. (Learn more about CodeQuest here.)
VoiceOver Commands Active
Many educational apps require drag-and-drop gesture or command, which can be accessible with VoiceOver if the developer has included VoiceOver command. There are two pieces to making drag-and-drop accessible. The first, is to activate the VoiceOver command for drag-and-drop (which is double tap and hold, then drag). The second piece is that as you are dragging, the user needs to know what he is dragging over in order to know where to release the draggable item.
Example: In the inaccessible Word Wagon app, there are three empty boxes and three draggable letters. When the student drags or right swipes to a letter, VoiceOver should announce that letter. When the student initiates the drag-and-drop command, VoiceOver will make the triple tone sound (indicating that drag-and-drop has now active). When the student drags over the box, VoiceOver should announce “box 1, empty” or announce what is currently in that box such as “P, box 1”.
Word Melodies is an app with a series of reading and writing games, including a similar drag-and-drop game which is fully accessible. Learn more about Word Melodies here.
Low Vision Accessibility
Many screen reader users do have some functional vision; apps should include low vision accessibility as well as screen reader accessibility. There are specific standards for low vision accessibility, but here are a few things to keep in mind:
- High contrast colors
- Accessible fonts
- Accessible sizes of letters, buttons, images, etc.)
- Uncluttered background
Settings
Offer settings and features so that users can choose their preferred settings. This might include low vision settings, but also mainstream choices such as turning the music on/off, how many items on the screen, etc. These settings will vary depending on the app content.
VoiceOver Sequence
While this is not as critical as the items mentioned above, it is still important and is often overlooked by developers. When opening a page, the VoiceOver focus is automatically on the first item on the screen (often that first item is the Back button in the top left corner). If the student right swipes, the VoiceOver focus should move in a systematic way (in a row left to right) across the screen – moving through each item until reaching the last item on the screen. The VoiceOver focus should not jump randoming around the screen.
Note: There are some apps that it is appropriate that when the page opens, the VoiceOver focus will be on the main content and not on the Back button. Example: In a math app, the VoiceOver focus might start on the directions or the math equation at the top of the page and not on the Back button.
Below are two videos of popular mainstream educational apps that demonstrate common accessibility issues.
The first video is the Hungry Fish app, a math app. This app has an animated graphic with fish and bubbles moving around the screen. The app itself is not accessible with VoiceOver.
The second video demonstrates a number line app that is almost accessible. When checking the VoiceOver sequence when right swiping across the app, this app has numerous VoiceOver announcements for things that are hidden (not visually on the screen). Note, you can hear the three tones that indicate drag-and-drop is active, but drag-and-drop does not work.
By Diane Brauner
