Please note that this document is a draft and still not finalized.
This page describes how accessibility guidelines are implemented in Mobility web and mobile applications.
What is Digital Accessibility?
Accessibility is the practice of making information, activities, and/or environments sensible, meaningful, and usable for as many people as possible. Digital accessibility ensures that all users can perceive, use, and operate web content, software, mobile apps, and other forms of digital media. Accessible means a person with a disability is afforded the opportunity to acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability in an equally effective and equally integrated manner, with substantially equivalent ease of use.
Web Accessibility
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:
perceive, understand, navigate, and interact with the Web
contribute to the Web
Web accessibility depends on several components working together, including web technologies, web browsers and other "user agents", authoring tools, and websites.
Mobile Accessibility
"Mobile" is a generic term for a broad range of wireless devices and applications that are easy to carry and use in a wide variety of settings, including outdoors. Mobile devices range from small handheld devices (EX. feature phones, smartphones) to somewhat larger tablet devices. mobile accessibility generally refers to making apps more accessible to people with disabilities when they are using mobile devices.
Accessibility Implementation in Mobility Web Application
Making the web application accessible
World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the web. It is responsible for creating and maintaining the Web Content Accessibility Guidelines (WCAG). WCAG defines how to make digital content more accessible and usable for people with a wide range of physical, sensory, and cognitive abilities.
The current version of WCAG (2.1) consists of thirteen guidelines, organized around four principles (POUR) of accessibility: Perceivable, Operable, Understandable, and Robust. Each guideline is accompanied by testable success criteria, which are linked to explanations and relevant techniques
In the mobility web project, the above-mentioned W3C WCAG (2.1) guidelines were taken into consideration for the development of accessibility.
Within each guideline are success criteria that are specific enough to be testable. These criteria fall into one of three levels: A, AA, and AAA, which build on one another.
Level A covers basic accessibility requirements.
Level AA is the international best practice and is usually the level required in legislation.
Level AAA is considered advanced conformance and sometimes includes elements that are more difficult to implement.
To meet a particular level, you first have to meet the one that precedes it. To reach level AA, you also have to meet all of the A criteria.
For the initial phase of accessibility implementation, here, we’ve considered only the Level- A Accessibility implementation.
Making the web application accessible
Create Perceivable Content
The current implementations,
Provide text alternatives (‘alt text’) for non-text content
Provide transcripts for audio and video
Provide captions for video
Make sure content is structured logically and can be navigated and read by a screen reader - this also helps if stylesheets are disabled
Use the proper markup for every feature (for example, forms and data tables), so the relationships between content are defined properly
Do not use color as the only way to explain or distinguish something
Use text colors that show up clearly against the background color
Make sure every feature can be used when text size is increased by 200% and that content reflows to a single column when it’s increased by 400%
Avoid using images of text
Make sure your service is responsive - for example to the user’s device, page orientation and font size they like to use
Ensure the Interface Is Operable
The current implementations;
Make sure everything works for keyboard-only users
Let people play, pause and stop any moving content
Do not use blinking or flashing content - or let the user disable animations
Provide a ‘skip to content ' link
Use descriptive titles for pages and frames
Make sure users can move through content in a way that makes sense
Use descriptive links so users know where a link will take them, or what downloadable linked content is
Use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you’re using in the interface
Make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on - this is known as ‘active focus’
Make the Website Understandable
The current implementations,
Use plain English/simple language
Keep sentences short
Do not use words and phrases that people won’t recognize - or provide an explanation if you can’t avoid it
Explain all abbreviations and acronyms, unless they are well known and in common use - for example, UK, EU, VAT
Make it clear what language the content is written in, and indicate if this changes
Make sure features look consistent and behave in predictable ways
Make sure all form fields have visible and meaningful labels - and that they’re marked up properly
Make it easy for people to identify and correct errors in forms
Build Robust Web Content
The current implementations,
Use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
Make sure your code lets assistive technologies know what every user interface component is for, what state it’s currently in, and if it changes
Make sure important status messages or modal dialogs are marked up in a way that informs users of their presence and purpose and lets them
Interact with them using their assistive technology
Let the user return to what they were doing after they’ve interacted with the status message or modal input