"According to the World Health Organization (WHO), over 1 billion people worldwide have some form of disability (57 million in the United States alone) - a number that is only increasing as the population ages." - World Health Organization Statistics
Don't Make Assumptions
"There can't be that many people with disabilities that use this app"
If one person with disabilities uses your app, you need to make accessibility considerations. It's important to consider situational and temporary disabilities as well.
Potential Disability Considerations
Mobility
Situational: Bruised knee
Arthritis, amputation, paralysis
Vision
Situational: Eye scratch, dilated pupils, you walked outside of a dark room on a sunny day
Color blindness, loss of vision, night blindness
Cognitive
Situational: Concussion
Memory loss, brain injury, dyslexia, ADHD
Hearing
Situational: Air pressure from flying in a plane, a night or morning after a concert, migraine.
Missing high-pitched or low-pitched sounds, total hearing loss in one or both ears
Adopting Accessibility Inclusion Early Will Save You Time and Money
If you've read or heard me talk on this subject before, I sound like a broken record. If we make accessibility considerations from the beginning of an app. This will take buy-in from the business as well but will save us budget in the long run and time.
Beginning of owning an app, audit the existing application to see what the current state of accessibility is and then make an effort to update accessibility as soon as possible. Create maintenance tickets to address these concerns and don't lose them in your backlog.
Avoid Lawsuits and Bad Practices
None of us want to get to this point. Having confidence that your team has been mindful of accessibility throughout your development lifecycle will ensure that your app will not be targeted by lawsuits.
Incorporate Accessibility Requirements Within Your Tickets
To ensure new features or updates to existing features include work for accessibility, it's important to include accessibility acceptance criteria such as adding labels, tags, screen reader enhancements, and dynamic fonts, to enhance and create the most accessible additions and updates to your project as possible.
Accessibility Acceptance Criteria Examples
Stick to clear gherkin scenarios
Provides Given > When > Then criteria
Stick to clear nomenclature
"Link component" or "video player"
Stick to clear action words
Focus, hear, click, scroll, hover
Stick to simple scenarios
More granularity is important here. If it's encompassed in a development effort, likely one scenario
As a **low-vision** user
GIVEN an image container
WHEN the user focuses on an image container
THEN the user can/should see alt-text on hover hear alt-text on screen reader
Add Accessibility Acceptance Criteria to Tickets
- Example: Use the device screenreader to ensure the expected screen reader experience
- Long-term - Short term - Situational As referenced earlier, there are severities when considering disabilities. Using the POUR principles - we can categorize these as well as note severity examples.
Stay True to Native Functionality and Consistency
Native functionality
Users become accustomed to the native behavior and appearance of their devices. Developers and Designers must consider native application behavior and appearance when creating, maintaining, and enhancing an application.
Straying too far from native behavior and appearance can confuse any user. This is also an accessibility issue.
Consistency
Piggybacking off of native functionality which is also a consistency concern, it's important to make sure your application is consistent throughout with functionality and design. You want to make sure that selections, forms, appearance, etc stay the same throughout the app.
Other Accessibility Concerns for Mobile Applications
- Touch target sizes including button placement and size
- Ensure text size is dynamic and can be enlarged or reduced in size with native accessibility options.
- Important elements should appear on the screen before scrolling is necessary. Ensure scrolling is free from barriers.
- Screenreader labels, switch tabbing, and alternative gestures work as expected.
Top comments (0)