Accessibility in Unqork

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 End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. 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 Inclusive or inclusivity has a broad definition that includes or covers all parties, services, and facilities involved in any way of life..

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: https://www.w3.org/WAI/standards-guidelines/wcag/.

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 to make it more distinguishable.

Robust

Ensure your application is compatible with current and future assistive technologies.

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.

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 asked to input 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 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 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 here: 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 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.

Accessible Features in Unqork

Unqork continuously makes improvements to the platform to help you build faster and smarter. But Unqork also performs regular audits to improve inclusivity 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.2 guide. 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 configurations.

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 applications more inclusive.

To take advantage of these new features, please contact your Unqork representative to enable these settings in your environment.

The following settings are available in most of Unqork’s UI input components:

Setting	Description
Aria	Use these settings to create ARIA (Accessible Rich Internet Applications) attributes to better support end-users who require screen readers to navigate your applications. To learn more, view the Resources section of this article.
Aria Label	Use this field to define the component when a screen reader arrives at it on the front-end.
Aria Role	ARIA roles provide semantic meaning to content, letting screen readers and other accessibility tools present and support interaction with an element that is consistent with end-user expectations. ARIA roles are used to describe elements that do not exist in HTML or are not supported by the browser.
Autocomplete	Autocomplete detects end-user data saved in a browser and uses it to fill relevant fields. For example, in Express View, if there is a field labeled First Name, and an end-user clicks into the field, the end-user's browser autofill function suggests first names saved to the browser. To learn more, view the Resources section of this article.
Autocomplete Value	When Autocomplete is enabled, the Autocomplete Value drop-down displays. Use this drop-down to select an ARIA role to better direct the autocomplete feature when an end-user clicks on a field. For example, selecting address-line1 helps the browser determine that the field should autofill with the first line of an address.
Input Behavior	Controls how end-users interact with the component on the front-end.
Enable User Input	Allow end-users to view and enter data in this field.
Disable User Input	Prevents end-users from entering data in the field, but lets them view it. In the Module Builder, the field’s background displays as gray. In Express View, when end-users hover over the field, their cursor displays with a prohibited symbol.
Read Only - Legacy	Prevents end-users from entering data and replaces the field with the component’s data value. If no value is provided, the component displays None.
Read Only - Accessible	Makes the field non-editable and applies the readonly HTML attribute, which notifies screen readers that the field cannot be modified.

Below is a list of components based on the accessibility settings they support:

Enable User Input, Disable User Input, Read Only - Legacy	Enable User Input, Disable User Input, Read Only - Legacy, Read Only - Accessible	Autocomplete	Aria Label	Aria Role
Button	Address v1	Date Input	Button	Columns
Checkboxes	Address Search	Number	Columns	Field Group
Data Grid	Date Input	Phone Number	Field Group	Panel
Data Table	Email	Text Area	Panel
Dropdown	Intl Phone Number	Text Field
File	Number
Map v2	Phone Number
Matrix	Text Area
Multi-Select Dropdown	Text Field
Navigation
Plaid
Protected Field
Radio Buttons
Rich Text Editor
Signature
Single Checkbox
Vega Chart

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.