Making programs for everyone
People use programs in different ways. Some need larger text, some cannot hear a sound, and some use a keyboard instead of a mouse. Accessibility means helping people use your program with their different needs and ways of interacting.
You do not have to solve every design problem in your first project. Start by making instructions clear and important information available in more than one way.
Give a useful clue
Imagine a game that only flashes red when a player loses a life. What if the player cannot distinguish that color? A message such as “One life remaining” gives another clue. Sound can be an extra clue, but it should not be the only one either.
Use labels that explain an action. “Start game” is clearer than an unexplained triangle. Leave people enough time to read, and avoid unnecessary flashing or moving effects.
Write a clear status message
This small example works in a text output panel. It demonstrates the wording of a status message, not a complete accessible graphical interface.
# language: en
let lives = 1
if lives == 1:
say "1 life remaining. One more hit ends the game."
else:
say "Lives remaining:", lives
say "Read the instructions before you start."
Predict, then run
Does the player need to recognize a color or hear a sound to understand this warning?
1 life remaining. One more hit ends the game.
Read the instructions before you start.
The words explain both the state and its meaning. An actual app also needs to present that text in a readable way. Text drawn onto a canvas is not automatically exposed as useful text to a screen reader; host and interface support matter.
Your challenge
Write the message for zero lives. It should explain that the round has ended and describe a real next action your program supports. Do not offer a Restart button that you have not implemented.
A common mistake
Assuming “I can use it, so everyone can” misses other experiences. Ask someone to try your project without explaining each step. Can they understand the labels? Try keyboard controls where the host supports them, larger text, and muted audio. Keep feedback about the program, not about the person’s ability.
Where next?
Input · Drawing text · Testing