Roughly one-fifth of the world's population lives with disabilities. And statistics show that this percentage continues to increase over time. But, disabilities aren’t only physical ones that hinder one’s mobility. Many types of disabilities make it difficult for end-users to use your application.
Types of disabilities that affect how an end-user interacts with your application include:
Auditory: Deafness or serious difficulty hearing.
Visual: Vision loss or decreased ability to see. This disability includes end-users who have difficulty perceiving specific color palettes.
Neurological: Disorders affecting the brain, spinal column, and nerves. This type includes dyslexia, a common disability that affects how end-users interact with applications.
Speech: Difficulty creating or forming the speech sounds needed to communicate. This disability makes it difficult for end-users to use voice-activated applications.
It's understandable why the above disabilities can affect the end-user's experience with your application. But accessibility goes even further than that. Consider the limitations of your application when end-users:
Do not have access to a mouse or prefer to interact with a keyboard.
Have changing abilities due to aging.
Live in rural areas with limited resources.
To meet the accessibility requirements of all end-users, keep these principles in mind. People with and without disabilities must be able to perceive, understand, navigate, interact, and contribute to your application.
The Web Accessibility Initiative
People with disabilities often need nonstandard browsers and devices with limited resources, like mobile devices. So, your application must be accessible to provide equal access and opportunity to people with diverse abilities. For example, let’s consider that you have a visually impaired end-user. Most likely, that person uses screen reader software to read the text on a webpage. They also might use the browser zoom to read the content. The screen reader software needs to read the tag associated with the opened tab, the application’s text, any dynamic fields that require input, and all image tags. And your application needs to quickly render when zoomed in and scaled to 200% (at minimum). Every feature of your application must be accessible to your visually-impaired end-users.
According to the United Nations' CRPD (Convention on the Rights of Persons with Disabilities), access to information and communications technologies is a human right. In 1994, a global community of experts developed internet accessibility standards. The W3C (World Wide Web Consortium) is the international standards organization working to make the internet inclusive.
To learn more about the W3C, visit their website here:
https://www.w3.org/.
In 1997, the W3C created the WAI (Web Accessibility Initiative) to improve internet accessibility for people with disabilities. In 1999, the WAI created the first version of the WCAG (Web Content Accessibility Guidelines). These guidelines help designers improve the accessibility of web content, websites, and applications on desktops, laptops, tablets, and mobile devices.
To learn more about WCAG guidelines, visit the W3C website here:
The most recent WCAG contains 12 guidelines, broken up into four principles, to improve digital accessibility. Together, these four principles make the acronym POUR. Below are the descriptions and key attributes of each principle:
Perceivable
Provide text alternatives that the end-user might need. Examples include large print, braille, symbols, spoken content, or straightforward language. |
Provide alternatives for anything embedded in an application that moves and creates sound. Time-based media also includes content synchronized with another site element and content that changes without end-user input. |
Present content in different ways without losing information or structure. A more straightforward layout might be the simplest way to be adaptable. |
Make it easier for end-users to see and hear your content. For instance, separating the application's foreground from its background makes it more distinguishable. |
Operable
Make all your functionality keyboard accessible without the use of a mouse. |
Ensure your end-users have enough time to read and use the application's content. |
Avoid designing content that might cause seizures or physical reactions. This includes content that flickers, flashes, or blinks. Also, avoid animations and visual patterns, such as stripes. |
Ensure your application is navigable, so end-users can locate content and know where they are in your application. |
Provide input modalities for your end-users, including mouse, keyboard, speech, and touch input. |
Robust
Ensure your application is compatible with current and future assistive technologies. |
Understandable
Ensure content is readable and understandable. |
Ensure web pages open, display, and operate in predictable ways. |
Use input assistance to help end-users avoid and correct mistakes when entering information. |
Designers can work with accessibility resources or a WCAG checklist to meet accessibility requirements. The level of compliance depends on how closely applications meet these guidelines.
Compliance Level | Description |
|---|---|
Level A | Satisfies only the Level A success criteria. This is the lowest level of accessibility. |
Level AA | Satisfies all Level A and Level AA success criteria, and all the most common accessibility issues are addressed. |
Level AAA | Satisfies all Level A, Level AA, and Level AAA success criteria. The highest standard of accessibility. |
Now that you understand the importance of digital accessibility, learn how you can incorporate it into your Unqork builds.
Testing Your Builds
The key to configuring an accessible application is to test as you build. Efficient testing helps you avoid recreating functionality. There are many helpful tools and resources online to ensure you add accessible features to your builds.
It is the responsibility of the customer to build and test your applications using accessibility guidelines. Unqork only provides helpful tools to achieve these tests.
The first resource is a WCAG checklist. The most up-to-date version is available on various websites as a fillable PDF or quick reference guide. The checklist provides information like:
Updates and additions have been added to the newest version of the WCAG.
A breakdown of the types of accessibility needed to meet compliance levels.
A dynamic checklist to help you track your progress.
Most checklists also include suggested tools to help you improve the inclusiveness of your builds. Most of the better tools are free extensions from the Chrome Web Store: chrome.google.com.
Accessibility Tool | Description |
|---|---|
Accessibility Multitool | The WAVE is an all-in-one tool from WebAIM. This tool displays errors associated with small text sizes, incorrect heading cascades, and missing alternate text or aria (accessible rich internet applications) attributes for screen readers. It also has a simple color contrast analyzer. |
Color Contrast | The free Colour Contrast Analyser tool is more robust than the WAVE's simple analyzer. This tool lets you enter background and foreground CSS color formats manually or use the color picker tool. The tool provides you with detailed information about the colors and contrast ratio. If your color contrast fails per the WCAG, the tool gives you an explanation. Lastly, the tool comes with a built-in color-blind simulator to help you select appropriate colors for your application. |
Screen Reader | There are a lot of screen readers on the market. Some are free, while others require a one-time or subscription fee. The most popular free screen readers are NVDA for Windows, VoiceOver for MAC OS/iOS devices, and Talkback for Android devices. Google also has a Screen Reader extension. Use this extension to read checkbox, drop-down, and radio button options. Also, use it to read each letter or symbol that end-users enter into a field. |
Content Scaling | Low-vision end-users need to use the browser's zoom feature to help them identify and read smaller content. Applications must allow for content scaling up to 200% without loss of functionality. |
Mobile Accessibility | There are a couple of tools specifically for mobile applications. The Accessibility Scanner checks for accessibility in Android apps, while the Accessibility Inspector checks accessibility in iOS apps. |
Considerations
While Unqork provides these new accessibility settings for use, it's the responsibility of the customer to implement and maintain accessible applications.
Not all Unqork components have the enhanced settings available to the Creator, letting them meet accessibility compliance requirements.