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 you as the designer need to take into consideration.
“Today, we need to design with one thought to the color blind, one thought to the photosensitive epileptic, and one thought to those who will magnify our screens. Today we need to write semantic HTML and make pages that can be navigated by voice, touch, mouse, keyboard, and stylus.”
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 their 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.
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)
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)
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)
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
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.
Alphabet of Accessibility Issues by Anne Gibson
Understanding Target Size Under WCA G 2.2 and How It Affects People with Disabilities, Bureau of Internet Accessibility
Web Accessibility Initiative – Accessible Rich Internet Applications
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 is the process of translating a product into different languages or adapting a product for a specific country or region. When localization is performed on web content, information such as alternatives used by people with disabilities may inadvertently be overlooked.”
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 are software programs that allow blind or visually impaired users to read the text that is displayed on the computer screen with a speech synthesizer or braille display. A screen reader is the interface between the computer’s operating system, its applications, and the user. The user sends commands by pressing different combinations of keys on the computer keyboard or braille display to instruct the speech synthesizer what to say and to speak automatically when changes occur on the computer screen. A command can instruct the synthesizer to read or spell a word, read a line or full screen of text, find a string of text on the screen, announce the location of the computer’s cursor or focused item, and so on. In addition, it allows users to perform more advanced functions, such as locating text displayed in a certain color, reading pre-designated parts of the screen on demand, reading highlighted text, and identifying the active choice in a menu. Users may also use the spell checker in a word processor or read the cells of a spreadsheet with a screen reader.”
American Foundation for the Blind
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.
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 (focus state) 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. 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. Please refer to their website to view the requirements for components like dropdown menus, carousels, and modal dialogs
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 radio buttons or, in some cases, menu links.
- Right/Left arrow keys – in some cases, move between menu links or adjust sliders in audio and video plugins.
- Escape – Close the current modal dialog or dropdown menu and return focus to the element that spawned it.
Gestures, Touch & Pointer Targets
“Any on-screen element that someone can click, touch, or otherwise interact with should be large enough for reliable interaction.”
Google Material Design
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.
WAI-ARIA Overview, W3C
Alternative Text: What and Why, Bureau of Internet Accessibility
Alternative text, WebAIM
Labeling Controls, W3C
Charts & Accessibility, Penn State
Accessible Icon Buttons, Sara Soueidan
Keyboard Accessibility, WebAIM
Designing for Keyboard Accessibility, University of Washington
Guidelines for touch targets, Microsoft
User Interaction, Apple
Touch target size, Google
Accessibility Considerations for Localization, Level Access
Accessibility Considerations for Localization, Bureau of Internet Accessibility
Understanding Target Size Under WCAG 2.2 and How It Affects People with Disabilities, Bureau of Internet Accessibility
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.
“Both responsive Web design and accessibility rely on coding a site to standards…This includes separating the content from the display rules…Instead of thinking about a Web site like a printed page, with a fixed format, we give up that absolute control in favor of the flexibility that makes a good experience for more people possible.”
Layout & 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 discernable 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.
Responsive Web Design and Accessibility, UXmatters
Accessible Responsive Web Design (RWD), Interactive Accessibility
Responsive Web Design, Wikipedia
Layout and Hierarchy, Accessibility for Teams
Color & Contrast
“Approximately 0.5% of adult women and 8% of adult men (4.5% of the total population) have
some kind of color insensitivity. Color insensitivity can make it difficult to distinguish hues (red/green color blindness is the most common form), and some rare conditions prevent the perception of hue altogether.”
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.
To comply with accessibility display status color along with text and/or an icon.
Don’t rely on color alone to display status color.
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.
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.
Micro Focus strives to meet WCAG Level AAA in all of its products as much as possible, and at a minimum, meets WCAG Level AA. These are the W3C guidelines that apply to contrast ratios:
WCAG Level AA
WCAG Level AAA
Micro Focus has deliberately designed the components in its design system with high contrast that pass accessibility standards. Components should not be changed, however, if for some reason your product uses something different or you need to create new components, be sure to check the contrast levels of the text with the background color to ensure they meet accessibility standards.
All text colors comply with and pass accessibility standards in the out-of-the-box component.
The text color with the contrast of the background does not pass accessibility standards. Be sure to keep components as is.
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 the Color Blind plugin and validated with an online simulator.
Without 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 mild and usually doesn’t get in the way of normal activities.
- Protanopia and deuteranopia both make you unable to tell the difference between red and green at all.
- Tritanomaly makes it hard to tell the difference between blue and green, and between yellow and red.
- Tritanopia makes you 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.
Accessible Color, Workday
Contrast and Color Accessibility, WebAIM
Color Blind, plugin
What is Color Blindness?, Colblinder
Coblis — Color Blindness Simulator, Colblinder
“An accessible font is a font that will not exclude, nor slow down the reading speed of any … visitor, including those with blindness, vision loss, and reading disorders. Choosing the right font improves the legibility and readability … for everyone, helping [to] … reach a wider audience …”.
These typography guidelines relate more to accessibility issues, whereas the typography guides in our foundations discuss implementation, variations, and style choices that should be made when designing a UI. That said, Micro Focus’s default font for all interfaces is Roboto and complies with accessibility standards. However, in the use case where a product does not utilize Roboto, the following guidelines have been adapted from Accessibility for Teams and should be considered.
It’s important to note that not all fonts meet accessibility standards which is why it’s essential to follow these guides. Size, color, and contrast are some key features that can determine if a font is accessible, and some typefaces are easier to interpret and are seen more clearly than others, e.g.. decorative typefaces.
Use a large enough font size for body text so that people can comfortably read the content. Micro Focus’s default body text is 14px but this can vary depending on the interface it’s being used in, and the style of the font.
Maintain a line length that promotes comfortable reading. Don’t make lines too long or too short. Body text should be between 50-60 characters per line, including spaces. Headings should be between one to two lines and subheadings should be three to five lines.
If not using Roboto, choose a typeface that emphasizes clarity and legibility.
The typeface should perform well when it’s small or large and should maintain a consistent look and feel.
It has a large x-height.
The character is large for its point size.
The metrics (such as x-height) are consistent between letterforms.
Individual letterforms are distinct in shape and can’t be confused with others.
For example: I, l, and 1 are distinct. 0 and O are distinct.
The typeface supports all of the characters and font styles that are needed.
Use headings to communicate hierarchy. Ensure heading styles differ from paragraph text by some combination of size, weight, face, or color. This ensures that they are distinct from paragraph text but are related to each other with some consistency, which helps with scanning the content.
Use type size and line width to determine a line height that people can comfortably read. The larger the type size and line width, the larger the line height should be. Lines that are leaded too tightly or loosely can reduce readability by making it harder for the eye to know where to return to when the line breaks.
Using accessible fonts is not optional. In some countries, using an inaccessible font runs the risk of potential legal action. Therefore, if Roboto is not implemented, be sure to use accessible fonts that adhere to the Web Content Accessibility Guidelines (WCAG) as it is essential for compliance with some web accessibility laws, as in the US.