Building Accessible Applications in Unqork

Estimated Reading Time:  10 minutes

Overview

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 your end-user's experience with your application. But accessibility goes even further than that. Consider the limitations of your application when end-users:

• Don’t 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.

When designing and developing an application, it must be accessible to all end-users. 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 app’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.

Accessibility isn’t about pleasing customers. According to the United Nations 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.

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.

The most recent WCAG contains 12 guidelines, broken up into 4 principles, to improve digital accessibility. Together, these 4 principles make the acronym POUR. Below are the descriptions and key attributes of each principle:

Principle	Description
Perceivable	The perceptive elements include text, layout, media, and sound. End-users must comprehend the depicted information. Here are some ways to make your applications more perceivable.
Text Alternatives	For nontext content, provide alternatives that the end-user might need. Examples include large print, braille, symbols, spoken content, or straightforward language.
Time-Based Media	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.
Adaptable	Present content in different ways without losing information or structure. A more straightforward layout might be all you need to be adaptable.
Distinguishable	Make it easier for end-users to see and hear your content. For instance, separating the foreground from the background of your application.
Operable	Allowing everyone the opportunity to interact with your application is essential. You can't require your end-user to interact with the application's interface if the end-user doesn't have the ability. Here are some ways to make your applications more operable.
Keyboard Accessible	Make all your functionality available using only a keyboard.
Enough Time	Ensure your end-users have enough time to read and use the application's content.
Seizures and Physical Reactions	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.
Navigable	Ensure end-users can navigate, locate content, and know where they are in your application.
Input Modalities	Provide various inputs for your end-users, including mouse, keyboard, speech, and touch input.
Understandable	Your application's interface should be easy to follow and understand. Here are some ways to make your applications more understandable.
Readable	Ensure text content is readable and understandable.
Predictable	Web pages must open, display, and operate in predictable ways.
Input Assistance	Help end-users avoid and correct mistakes when asked to input information.
Robust	Your application must be robust enough so assistive technologies can interpret it. These technologies include screen readers and spell checkers.
Compatible	Ensure compatibility with current and future assistive technologies.

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. The 3 levels of compliance are:

• 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 is to test builds as you go. Testing is efficient and helps you avoid recreating functionality. There are many helpful tools and resources online to ensure you add accessible features to your builds.

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 added to the newest version of the WCAG.

• A breakdown of the types of accessibility needed to meet the different 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. Below is a list of a few free tools:

• Accessibility Multitool: The WAVE is an all-in-one tool from WebAIM. The tool shows you 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 simple analyzer of the WAVE. The 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 you type into fields.

• Content Scaling: Low-vision end-users need to use the browser's zoom feature to help them identify and read smaller content. Apps 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.

There are more tools to explore, but use this list to help you get started with your builds.

Accessibility in Unqork

Unqork continuously makes improvements to the platform, so that you can build faster and smarter. But Unqork also performs regular audits on the platform to ensure it's inclusive for your end-users. Unqork's audits involve using the previously mentioned tools, and Express View tests. This is all part of Unqork's desire to exceed Level AA compliance per the WCAG 2.1 version. 2.0. This compliance helps Unqork meet the requirements set by the commissions and departments that enforce accessibility laws like the ADA (Americans with Disabilities Act) and AODA (Accessibility for Ontarians with Disabilities Act). As Unqork improves inclusiveness, you can take advantage of it in your builds.

At the very least, end-users need to navigate your application with a keyboard and screen reader. End-users typically use the Tab key to navigate a webpage. And the screen reader must identify all fields, drop-down options, and image alternate and aria text. This section explores the different components that help make your builds more inclusive.

Primary Field Components

Primary Field components are great for creating forms to add text and use drop-downs dynamically. The Primary Field component doesn't require special configurations to add accessibility to your build. After setting up the following components, keyboard and screen reader functions work correctly:

• Multi-Select Dropdown component

• Number component

• Single Checkbox component

• Text Area component

• Text Field component

Many other Primary Field components meet the exact requirements with minor configurations. For instance, the Checkboxes, Date Input, Dropdown, and Radio Buttons components are keyboard and screen reader accessible if you set the Express View Preview Style as unqork-v2. This Preview Style is best practice for making your applications more accessible.

Secondary Field Components

As with the Primary Field components, Secondary Field components must also be accessible. This group of components is primarily visual and dynamic, so they need to work for keyboard users and screen readers. After setting up the following components, keyboards and screen readers function as expected:

• Address Search component

• Button component

• Email component

• Intl Phone Number component

• Password component

• Phone Number component

The Signature component is a perfect example of a component that is useless to keyboard users when configured without accessibility in mind. But there are ways to work around the Signature component:

• You can configure a Text Field in place of the Signature component. End-users can enter their full name as a signature instead of using a mouse, touchpad, or touchscreen.

• You can replace the need for a signature with a checkbox confirming the end-user has read and understands the specifications of your form.

Display & Layout Components

Now, look at the Display & Layout components. This set of components adds organization and structure to your applications. But, if you use panels, columns, grids, or tables, keyboard navigation must be available to your end-user. The following components have keyboard and screen reader accessibility:

• Advanced Datagrid component

• Columns component

• Content component

• Data Grid component

• Field Group component

• HTML Element component

• Matrix component

• Navigation component

• Panel component

• Rich Text Editor component

• Table component

• ViewGrid component

Charts & Graphs Components

You can also find accessibility in Unqork's Charts & Graphs components. Your screen reader announces the chart content and options as you tab through them on your keyboard. The following Charts & Graphs components can help your KPIs and maps be more accessible:

• KPI

• Map

• Chart

• Map V2