Accessibility

When designing interfaces, be it for web, tablet, or mobile, it’s important to know that everyone viewing that UI will interpret it differently. A user may have a visual, auditory, mobility, or cognitive disability that designers and developers need to take into consideration.

While putting together these guidelines Micro Focus referenced many resources and design systems. Especially the World Wide Web Consortium (w3c.org), the leading source that sets guidelines for an all-inclusive web. W3C is used internationally, and one of its main initiatives is to provide “strategies, standards, [and] resources to make the Web accessible to people with disabilities.” The Web Content Accessibility Guidelines (WCAG) contained on W3C’s website is part of a series of web accessibility guidelines that have been published by the Web Accessibility Initiative (WAI) and the W3C. These guidelines are meant to serve as a resource so that Micro Focus can be sure all products are accessible and “available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.”

W3C has four basic principles of accessibility which are the success criteria for anyone who wants to use the web. Micro Focus aims to use these principles as the foundation of its accessibility in its products, and if any of these are not true, users with disabilities will not be able to use the product. A brief description of each, as written on their website, is below:

Perceivable: Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to comprehend the information being presented (it can’t be invisible to all of their senses)

Operable: User interface components and navigation must be operable. This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)

Understandable: Information and the operation of the user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding, comprehension, or ability)

Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

Meeting accessibility guidelines

In addition to the four basic principles of accessibility, WCAG has three levels of compliance within WCAG 2.0 and, most recently, WCAG 2.2:

• A – lowest/minimal compliance
• AA – middle/acceptable compliance
• AAA – highest, optimal compliance

Each level has a set of criterion for all elements in an interface that it must meet to deem the interface accessible for all users. The differentiation between the levels gives developers and designers a structure for minimal, acceptable, and optimal accessibility. The levels also provide more flexibility so even advanced technologies can maintain a minimum level of compliance. It’s important to note that each version of the WCAG guides builds upon the previous version and is not meant to replace it, so to resolve and validate any accessibility topics be sure to reference all versions of the WCAG guidelines. There are also several checklists available to view.

How to use this documentation

The subject of accessibility is an immense topic and this documentation is ever-evolving. On the following pages, you’ll see some of the main topics Micro Focus felt were important to delve into. For each topic, we’ve also provided our sources and additional resources for you to explore further.

Web Accessibility Initiative – Accessible Rich Internet Applications

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification developed by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). It defines a way to make web content and web applications more accessible to people with disabilities, especially those with visual, auditory, physical, cognitive, and neurological impairments. It does this by providing additional attributes that can be added to HTML elements to provide additional information about the role and state of those elements, and how they can be interacted with. This can help assistive technologies, such as screen readers, better interpret and present web content to users.

WAI-ARIA technology makes the following accessibility topics possible for developers to make products and web applications usable and accessible to users with disabilities. Therefore, designers and developers must work together so the developer can hierarchically structure the back-end code so that WAI-ARIA technologies relay content in the same intuitive and ordered way that the designer intended the layout for a user without disabilities would interpret the interface.

Localization

As Level Access explains, some aspects of accessibility that are often overlooked include the following:

• Language attributes (i.e. the lang attribute)
• Image alternatives (e.g. alt attributes)
• Title attributes
• ARIA-label attributes
• Off-screen positioned CSS text (e.g. className sr-only)
• Table summary attributes
• Page titles (these are hidden more in tabbed browsing and may be overlooked)
• Long descriptions (e.g. the longdesc attribute)

Localizing an interface introduces some additional concerns for accessibility, and in order to make an interface accessible for all its intended users, designers and developers need to consider the following: translating the text of an interface, adjusting for different time zones, changing the format of dates, times, measurements, and addresses. After the UI has been localized, it must go through testing to be sure it remains functional and that the accessibility considerations have been preserved.

Screen readers

Screen readers are software programs that assist blind or visually impaired users in reading text displayed on a computer screen. They use a speech synthesizer or braille display to convert the text into a form that can be understood by the user. The user can control the screen reader through a combination of keyboard commands, which allow them to perform a variety of tasks such as reading or spelling out words, reading lines or full screens of text, finding specific strings of text on the screen, and announcing the location of the cursor or focused item.
In addition to these basic functions, screen readers also offer more advanced capabilities such as reading text displayed in a certain color, reading designated parts of the screen on demand, reading highlighted text, and identifying the active choice in a menu. They can also be used to access the spell checker in a word processor or to read cells in a spreadsheet. Overall, screen readers serve as an important interface between the computer’s operating system, its applications, and the user.

As per the National Center for Biotechnology Information (NCBI), in 2015, it was estimated that 253 million people worldwide were visually impaired. Of these, 36 million were blind and 217 had a moderate to severe visual impairment. Some of the more common vision impairments include loss of central, peripheral, or blurred vision, a generalized haze, and extreme light sensitivity. Micro Focus strives for inclusiveness, therefore, alternative text, which describes the function and appearance of an image or object on a given page needs to be implemented so that screen readers can dictate what’s visually on the screen. When adding alternative text, it’s important that it “represents the content and function of their images.” It should be localized in all languages that a product supports, and it should be descriptive yet concise so users with impairments are also able to understand the full picture.

In general, everything that isn’t text needs a label or a description for screen reader users. Besides images, this also includes charts and visualizations, icon buttons, text fields, checkboxes and toggles, drag and drop handles, etc. and alternative text should also be implemented for these components as well. There are various techniques for applying labels in each case, and unfortunately it is not sufficient to have descriptive text simply adjacent to these elements. One of the most common issues affecting screen reader users is form controls without adequate labeling. Every form control must have an associated label as the placeholder for text and text-like controls is not a substitute for a label.

Keyboard navigation

Most people navigate the web with a mouse or trackpad, but many people with disabilities browse the web using a keyboard. Users who have physical impairments or who lack fine motor control to navigate and interact with web controls rely solely on keyboard navigation. When a user interacts with onscreen elements, they use their keyboard to focus on individual elements, one at a time, by keystroking through them. Because keyboard navigation users don’t have automatic feedback as they would with a mouse or trackpad, they rely on visual indicators that inform them where the keyboard focus is on the page. Keep in mind that these users may have little or no use of their hands or even no hands at all, or they may suffer from tremors which don’t allow for fine muscle control. Blind users may also use a keyboard for navigation, as well as some users without disabilities because of personal preference or efficiency.

To ensure products and interfaces are keyboard accessible the following guides should be met:

• All links and controls in the interface can be accessed using the Tab key on the keyboard.
• It is always visibility apparent which element has focus.
• All interactive elements comply with the recommendations of the W3C’s Design Patterns for particular widgets. Each interactive element has specific requirements for how widgets should be operable with a keyboard. Refer to their website to view the requirements for components like dropdown menus, carousels, and modal dialogs.
• Avoid using apps, plugins, widgets, or JavaScript techniques that trap the keyboard and don’t give the user a clear exit. Users should be able to get into and out of any UI without trapping keyboard users.

Testing your products and UIs by using your keyboard to navigate between all links, buttons, form fields, and other elements is a great way to validate that your products are keyboard accessible. As mentioned above, focus states, and the current focus should be easy to see. The order of the focused states on the screen should echo the visual layout with a natural flow between content. There are also some questions you can ask yourself while testing your products:

• Can you access all features?
• Can you operate all controls?
• Can you tell where you are on the page?
• Does the focus wrap within the entire page or modal dialog?

Common keys used in keyboard operation:

• Tab – move to the next link, form element or button.
• Shift+Tab – move to the previous link, form element, or button.
• Enter – activate the current link or button.
• Space – check or uncheck a checkbox form element. Will also activate a button that currently has focus.
• Up/Down arrow keys – move between tabs or between menu items; move between radio buttons or other grouped items.
• Right/Left arrow keys – move between tabs or between menu items; sometimes between links; adjust audio/video sliders.
• Escape – Close the current modal dialog or dropdown menu and return focus to the element that spawned it.

Gestures, touch and pointer targets

Depending on the framework your product uses, there are different specifications for touch and pointer target sizes and you should reference them directly through the following links for Google, Apple, and Microsoft.

All products should aim for a minimum of Level AA in their interfaces and according to Success Criterion (SC) 2.5.8, which covers pointer target spacing, the minimum target size is 24px squared. “When a target is too small or located near another target, users may experience issues when operating controls or navigating to another page.” It should be noted that small pointer targets can affect anyone, including people who don’t have disabilities, and large, distinct targets can provide a better user experience for all users.

Relating specifically to touch targets, research indicates that the average adult finger pad measures 10mm, so a basic rule of thumb is that touch targets should not be any less than 10mm, or 44px squared. All users can benefit from a larger touch target, be it someone who has trouble with precision due to a motor or vision impairment, young users, or even a user that’s in an environment that limits their accuracy.

Gestures should also be taken into consideration so that they don’t interfere with existing gestures that use assistive technologies. If gesture already exists, design and build another mechanism to accomplish the same thing.

Responsive web design (RWD) is something that happens in the front end by adapting the layout of an interface to the size of the screen of the user’s device. It’s more about thinking of an interface as a collection of elements that can be rearranged and are not set in a static layout. Accessibility and accessible design are processes and methodologies of designing each screen of the UI to meet specific criteria in an effort to create interfaces that are available to all users no matter their background.

For example, an image in an interface has visual meaning and conveys information to the user. In order for this image to be responsive, it needs to be a flexible image so that it can adjust its size to the environment of the users’ screen. Whereas, for that image to meet accessibility standards, its color and contrast levels, its placement, and its alternate text all need to be considered.

If the content in your interface doesn’t utilize visual hierarchy or use proper spacing between elements you’ll have accessibility issues. If there isn’t enough color contrast you’ll have accessibility issues with those users that have a color limitation.

“Accessibility is designing for inclusion.” Responsive design is designing for usability.

That said, there are some aspects of responsive design that do correspond with accessibility. While responsive design wasn’t specifically developed to address accessibility, one of its goals is to adapt interfaces for the most optimal viewing experience and as a result, it addresses some accessibility issues. When a UI is designed responsively, it ensures that font size stays readable and at a high resolution for people with low vision, and interactive elements remain large and easier to operate for people with mobility impairments.

Layout and spacing

To comply with accessibility standards, elements within the UI need to be easily identifiable. Establishing space and hierarchy between content, and designing a visually clear structure within the interface helps to promote an accessible layout. Components such as navigation, form fields and labels, buttons, and the like should follow an understandable order.

As a designer or developer, there are some steps you can take to ensure that the layout is accessible:

• Be sure that key information is discernible at a glance.
• Design minimally and intentionally so that users can digest as much information as quickly as possible.
• Create a clear hierarchy by placing elements on the screen in order of their relative importance.
• Ensure that all content fits into a logical heading structure.
• The reading order should be considered and should be the same as the visual order.
• Group related items to help those with low vision or trouble focusing on the screen.

Discoverability refers to the ease with which users can find new content or features within a digital product. It is an important aspect of user experience because it affects the user’s ability to locate what they need and complete tasks. The term “discoverability” suggests the potential for something to be discovered, similar to the way the word sounds.

First, it’s important to distinguish between the terms discoverability and findability as they are often used interchangeably. Discoverability, as mentioned above, is the ability and ease with which a user can find all the elements and features within an interface when they first encounter it. Whereas findability is the ease and ability to find content or functionality that users already know or assume is present or available in an interface. This is a significant distinction to make because in many cases users are not intentionally looking for new features or functionality, especially those who are frequent visitors. And this is one reason why focusing on discoverability is a way for designers to make it easier for users to find new-to-them items and in turn, make products and interfaces more accessible.

There are many factors that can impact the discoverability of a user interface. The following is a list of tips, from XD Ideas can be applied to almost any product that aims to improve its UX discoverability.

• Design familiar interfaces
• Prioritize valuable content and features
• Group content and functional elements in a logical order
• Reduce visual clutter
• Reduce the total number of options
• Provide visual feedback
• Use icons with universal meaning
• Use animation to direct user attention
• Be careful with gestures
• Size UI elements appropriately
• Provide visual affordances
• Provide visual cues

Keep in mind that “if the user can’t find something, it doesn’t exist for them. Discoverability can help them find it. As designers, we should strive to create intuitive interfaces and experiences. By making our interfaces more discoverable, we increase the chances that users will encounter and use our content and features.”

When used effectively, color helps the user understand the purpose of content as well as communicate information users need to interact with. As such, color should never be used to convey meaning or as a primary mode of communication, but rather to enhance interfaces and lead the user to relevant details.

Additionally, color alone should not be used to communicate the status of a UI component. For example, a badge component is used to show the status of a service, with green indicating normal operation and red indicating a problem. This would be an accessibility issue for those users with a color insensitivity, and in this case, the solution is to combine the color difference with an icon or text that also indicates the status.

It’s also important to emphasize that not all users will see color/interfaces in the same way as one another or even in the same way as the design was intended. Therefore, it’s important to validate your designs with third-party tools or plugins to understand how a user with a vision sensitivity will interpret them.

Additional steps can also be made by the designer to help ensure that interfaces meet accessibility standards by finding colors that provide maximum contrast so that text and non-decorative images are legible for anyone with low vision or color deficiencies, this includes enough contrast between content and the background. All text, images of text, and icons should provide sufficient contrast (specific ratio requirements below) so that users can easily navigate and interact with the UI.

Contrast

Color contrast is displayed as a ratio that ranges from 1:1 to 21:1. The difference between the two numbers indicates how much relative luminance (relative brightness) there is between the foreground and background colors. The purpose of contrast ratios is to ensure that foreground content is easily visible on a background color.

Depending on font size and weight, color contrast ratios will vary. In general, ratios will be higher with smaller text, and as text gets bigger ratios will be lower due to the strokes on larger letters being wider and easier to read at a lower contrast ratio. It’s important to clarify that the contrast of a color itself does not change with font size, rather when the font size is smaller it becomes less clear and appears less vibrant. Contrast ratio requirements should be put in place and be properly met so that all users are able to read and interpret the content in a UI.

All Micro Focus products should strive to meet WCAG Level AAA, and Level AA as a minimum. These are the W3C guidelines that apply to contrast ratios:

WCAG Level AA – A contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
This means that text that is 14pt or below must meet a 4.5:1 contrast ratio, and text that is 14pt and bold or larger than 18pt must meet a 3:1 contrast ratio. This also applies to text, non-text content, and images of text and requires a contrast ratio of at least 3:1 for graphics and user interface components, such as form input borders.

WCAG Level AAA – A contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.
This means that text that is 14pt or below must meet a 7:1 contrast ratio, and text that is 14pt and bold or larger than 18pt must meet a 4.5:1 contrast ratio, and also applies to non-text content.

Color blindness

People who have color blindness means that they can not see colors the way most people can, and less commonly, may not see color at all. “Color perception in the human eye is built up by three different types of cones. Each type is sensitive to a certain wavelength of light (red, green, and blue) and every perceived color is a mixture of stimuli of those three cone types.” Therefore, there are three main types of color blindness that cause problems in seeing different colors. As adapted from NIH a brief description is below along with renderings that were created using a Figma Color Blind plugin and validated with an online simulator.

Red-Green
The most common type of color blindness makes it hard to tell the difference between red and green. There are four types of red-green color blindness:

• Deuteranomaly is the most common type of red-green color blindness. It makes the green look more red. This type is mild and does not usually get in the way of normal activities.
• Protanomaly makes red look more green and less bright. This type is also mild and does not get in the way of regular activities.
• Protanopia and deuteranopia both make it unable to tell the difference between red and green at all.

Blue-Yellow
Another, less common, type of color blindness makes it hard to tell the difference between blue and green, and between yellow and red, and there are two types of blue-yellow color blindness:

• Tritanomaly makes it hard to tell the difference between blue and green, and between yellow and red.
• Tritanopia makes it unable to tell the difference between blue and green, purple and red, and yellow and pink. It also makes colors look less bright

Complete color blindness
People who have complete color blindness don’t see color at all. This is also called “monochromacy” and is quite uncommon. Depending on the type, a person may also have trouble seeing clearly and may also be more sensitive to light.

As you can see from the examples above, when choosing colors in your product’s interface, it’s very important to not only choose colors that give a lot of contrast for those users with vision impairments but to also pair colors that are different enough to be distinguishable from one another so that a user who is color blind can differentiate between them. A guide that commonly works is to choose complementary colors (colors opposite on the color wheel) as these colors are typically different enough for someone that’s color blind to recognize that they are different colors.