Accessibility overview

Accessibility refers to the ways that your product is set up to support different user needs and abilities, making their experience more comfortable and ensuring that they can easily interact with information. PatternFly prioritizes accessibility, so if you contribute to our design system or use PatternFly for your products, you should first familiarize yourself with our accessibility guidelines and recommendations.

No user should feel left behind when using your product. The goal of accessible design is to remove barriers and create inclusive product experiences that work for everyone, regardless of ability. This is best achieved when accessibility is considered early in the design and development process, but it's never too late to start prioritizing accessibility.

There’s always room to improve accessibility. That’s why our guidelines will continually evolve. Your feedback can help create a more inclusive design system, so we welcome you to contribute to our accessibility documentation or get involved in our GitHub Discussions.

We are committed to testing our components and checking for accessibility compliance, aligning with level AA in the Web Content Accessibility Guidelines 2.2.

To ensure that PatternFly's components prioritize accessibility first, we build accessibility into our codebase.

As PatternFly is updated and enhanced, we put changes and new features through a combination of automated and manual testing, using aXe: The Accessibility Engine to ensure that all components pass an accessibility audit before they’re added to PatternFly.

We also regularly audit keyboard accessibility with both manual testing and integration tests. We aim to provide full support for VoiceOver as our main screen reader, but we still test our components through NVDA and JAWS. As part of our manual audit, every component is run through VoiceOver to make sure they’ll be as accessible as possible in your products.

We strive for compliance in accordance to level AA in the Web Content Accessibility Guidelines 2.2 across the core PatternFly HTML and React libraries, as well as our extensions. If you use or contribute to PatternFly, the following accessibility guidelines are some that you can expect PatternFly to adhere to (keep in mind this is not an exhaustive list):

We believe that all abilities should be treated equally. There should be parity in the experience of all users—one user group shouldn't be prioritized over the other.

To help you achieve this, consider these guidelines:

• Content should be optimized for all input types: touch, mouse, and keyboard.

  • Don’t optimize the experience for one input type at the expense of another.
  • Contents that are mouse-accessible should also be accessible using touch or a keyboard.
  • Don’t show interactive elements on hover.
  • Interactive elements that display in a pop-up must also display on click, touch, or enter-key events.

• Screen reader content should match visibly rendered content (refer to the first note for aria-hidden state, but keep in mind this references an older version of WCAG guidelines).

• There should be parity between hover and focus events. Any information that’s available on hover for the mouse user should be available on keyboard focus.

  • Make content that appears on hover available to a screen reader by using aria-describedby (refer to Tooltips & Toggletips example from Inclusive Components).

When building accessible user experiences, solving for one can extend to many. Humans are diverse and unique, and designing for accessibility takes that into consideration to create truly inclusive products.

A keyboard, used by some in place of a mouse, allows users to navigate through UI elements in the order that they appear on the page, typically using the <kbd>Tab</kbd> key. Keyboard users should be able to do anything that mouse users can, including viewing text that is shown upon hover or in popups.

A screen reader reads visible and non-visible content (like tooltips or alt text for icons, images, and linkes) aloud. When a user has impaired vision (temporary or permanent) that prevents them from viewing a screen, they can use a screen reader to access the content of a product or application.

Often, a user may navigate with a keyboard while using a screen reader.

This section provides information to help you better understand and address some of the needs of users with diverse abilities. It is important to note that some users might fall into multiple groups, and some might use tools created for a different group.

Users with reduced motor control often use a keyboard or computer mouse to access content. Some users may also have difficulty keeping a mouse steady when trying to interact with content.

To design for users with reduced motor control, remember that:

• Users who rely on a keyboard need elements that are keyboard accessible and highly visible when in focus.
• Users who rely on a mouse or touch need target areas that are large enough to be easily clicked and selected.

Users with no vision rely on screen readers to access web sites and applications. These users often navigate a page by observing specific elements, like headers, links, or form elements.

To design for users with no vision:

• Use semantic elements.
• Write labels that are meaningful when pulled out of context.

Users with low vision can have different needs depending on the nature of their visual impairment, such as difficulty with color differentiation, blurriness, or lack of vision in central or peripheral areas.

To design for users with low vision:

• Interfaces should not rely on color alone to communicate information.
• Palettes must have sufficient contrast.
• Layouts should be responsive to font size increases.

Users who have difficulty processing information benefit from well-written content.

To design for users with cognitive processing issues:

• Write content that is clear, concise, and easy to scan.
• Consider visual hierarchy and chunk content into short, related sections.
• Avoid long paragraphs.

While there are a few main accessibility needs, it is not an exhaustive list. Often the “Persona Spectrum”, coined by Microsoft (Download the Inclusive Guidebook as a PDF), can be used to understand related mismatches and motivations across a spectrum of permanent, temporary, and situational scenarios.

While accessibility tends to focus on those with permanent disabilities, everyone benefits from accessible products:

• Accessible content supports better comprehension across language fluency and literacy levels.
• Alternative text (alt text) makes images accessible to users with low bandwidth connections or older technologies that can’t load the images.
• Closed captioning benefits those in crowded areas, those learning how to read, and those learning a new language.

Accessibility takes all users into account.