Making off-screen content accessible

Introduction:

An off-screen content is a content that isn’t currently displayed, yet still needs to be in the DOM (modal-windowdrawer panel, …). This type of UI pattern presents an interesting challenge for accessibility because of the tab order and assistive technology‘s content linearization (more on this bellow). Today, I would like to explore a possible solution for making our off-screen contents accessible to keyboard users and other assistive technology.

 

Drawer panel menu, example of an off-screen content.
The drawer panel is a good example of off-screen content. Initially hidden to user while still being present in the DOM, it is only revealled to users in response of an event (Image from https://tympanus.net/codrops/2013/08/13/multi-level-push-menu/)

 

A word on content linearization:

The web page is browsed in a linear manner by devices like screen readers or keyboards, this means that elements are presented one at the time. So an off-screen content present on the DOM which is not visible to sighted users but not properly hidden to assistive technology might disrupt the reading flow of users who depend on these technologies (please refer to Web AIM section on content Linearization).

 

For a proper accessible experience, “the state of an off-screen content in the DOM should constantly mirror the page visual appearance”. (Make sure an element hidden to sighted users is also hidden at DOM level)

 

Experiencing non-accessible off-screen content from keyboard users perspective and finding a solution!

The experience:

Supposing a modal window isn’t properly hidden and receive focus when being off-screen. Users can be under the impression that the focus is disappearing and reappearing as they tab through the page — this is clearly an undesirable effect.

Ideally, while engineering the experience, developers should prevent the modal window from gaining focus when off-screen, and only allow it to be focused when the user can interact with it.

The solution:

During development, it is important to tab through the site to make sure the tab order doesn’t disappear or jump out of a logical sequence. If this is the case, developers should ensure that off-screen contents are properly hidden by using display:none" or visibility:hidden", and then set it back to “display:block" or “visibility:visible" before showing it to the user (This technique is implemented on this website’s drawer-panel menu).

 

As a rule, try tabbing through your pages every so often just to make sure you haven’t accidentally messed up the tab order. It’s a good habit to adopt, and one that doesn’t require much effort.

– developers.google.com –

 

Conclusion:

An off-screen content is a great way to dynamically reveal information on the page. But to avoid disturbing assistive technologies processing flow, off-screen contents must be properly hidden and revealed using CSS “display” and “visibility” properties.

Do you have experience with making an off-screen content accessible or are you struggling with one? Please share your thoughts with us. Thank you.

 

Resources:

 

 

Good usage of Keyboard traps: Example with off-screen components

Introduction:

Concentrating the user’s focus on a tiny section of the page can be a challenging task, especially when such an endeavor deteriorates the experience. The “keyboard trap” is generally seen as a UI bug where “the keyboard focus is being locked on a component for no apparent reasons” (refer to W3C article on keyboard trap), this an undesirable situation.

The “keyboard trap” can be seen in a better light if we look at some of the accessibility issues it solves. For example, a screen overlay prevents mouse users from accessing everything beside the content placed on focus, but keyboard users still have full access to anything on the page. In order to emulate the overlay effect for keyboard users, we can use the “keyboard trap”. In the following lines, I’ll show you how. In the meantime, see the keyboard trap in action.

 

 

What works for mouse users, doesn’t necessarily works for other users:

Consider a modal window. Because of an overlay that stands between the page content and the modal, mouse users have no access to anything on the page but to what’s inside the modal, not keyboard users. Looking at a drawer panel or any off-screen component, we see the same problem occurring: any HTML component that might isolate part of the layout for mouse users doesn’t do the same for keyboard users.

But we need the experience to be as consistent as possible for all users. Therefore, the “keyboard trap” will accomplish for keyboard users what the overlay is already doing for mouse users, which is keeping users focused on the modal content by forcing the keyboard focus to loop only on all focusable elements of that modal.

 

The “keyboard trap” can be used to “prevent keyboard users from moving the focus inatvertantly outside of a component!”

 

The implementation logic of the keyboard trap:

Whether the user opens a modal window or a drawer panel, the principle is the same: we have to make sure keyboard focus stays inside the active component.

Trapping the focus inside a component (modal window, drawer panel, …) can be simplified in the following steps:

  1. We get a reference to all focusable elements of the component (especially the first and the last)
  2. We use a “keydown listener” to track any key pressed especially the “tab”
  3. If “TAB” and “SHIFT” keys are pressed (tabbing backward)
    1. and the first focusable element is the one on focus, we move the focus to the last focusable element of the component (this creates a loop)
  4. If only “TAB” key is pressed (tabbing forward)
    1. and the last focusable element is the one on focus, we move the focus to the first focusable element of the component (this also creates a loop)

The full code on how to create a keyboard trap is available on Codepen.

 

Conclusion:

To preserve accessibility, it is imperative that we keep the same functionalities available to all users. In this case blocking access to anything but an off-screen content should be done not only to mouse users, but keyboard or other users as well. And we’ve just seen how the “keyboard trap” is a great solution for this.  Do you have experience with keyboard traps? Please share your thoughts with us.

Thank you.

 

Resources:

Web Accessibility – part 1 : Overview

Introduction:

Getting all users to fully experience the web without anyone being left out is on today’s front-end developer’s agenda. We then call “accessible” any web application which provides the same equivalent experience to a wide variety of users. In this article, we’ll discuss the following:

  • What is accessibility?
  • What are the different types of web impairment?
  • What’s make an application accessible?

If these questions appeal to your curiosity, then let’s proceed shall we?

 

Accessibility guarantees a seamless experience for a widest possible range of web users.

 

What is Accessibility?

Accessibility can be defined as the process of insuring that a product can be fully used and experienced in a similar fashion by the widest possible range of users.

Developers are often assuming that everyone else is experiencing the interface the same way they do, which leads them to create an experience that is only enjoyable by a small range of people, leaving the rest of the audience with issues (content not properly visible, understandable or audible). Therefore, accessibility adapts the experience to any user’s specific condition or situaton (it doesn’t matter whether users are in possession of all their faculties or have poor vision, bad hearing, etc …).

Accessibility goes beyond disability:

Accessibility integrate many elements of user experience, which minimize confusion and errors in people transactions on the web (for instance purchasing the wrong product because of the badly positioned call to action button). Accessibility therefore guarantees a seamless experience for a widest possible range of web users.

 

Accessibility incorporates User Experience

 

Example of accessibility and User Experience:

The following figure represents an inaccessible form. The issues are:

  • The username and price detail texts are low in contrast (hard for low vision readers to capture)
  • Labels and filters are each at the opposite side of the form (hard for people to associate them or to zoom into the page)
Form with accessibility issues (courtesy of https://udacity.com, web accessibility course)
Form with accessibility issues (courtesy of https://udacity.com, web accessibility course)

 

Now, here is the same form made more accessible by the following changes:

  • Low contrast text has been made darker (username and price detail texts)
  • The design has been modified to have label right next to their target (checking the label now affects the checkbox’s state)
Form optimized for accessibility (courtesy of https://udacity.com, web accessibility course)
Form optimized for accessibility (courtesy of https://udacity.com, web accessibility course)

 

Accessibility guarantees a seamless experience for a widest possible range of web users.

 

Understanding the diversity of  web impairments:

Impaired web usage is commonly associated with blindness, which is far from being accurate. In reality, there is four types of impairments on the web:

  • Visual : People with low visual acuity, poor color vision or suffering from concussion
  • Motor : People with a disabled arm or some other kind of dexterity impairment (they’ll probably use a special keyboard navigation, an eye tracking or voice dictation software)
  • Hearing : People who don’t or can’t listen. In this case, the content that uses a sound should provide some kind of visual alternative (a messenger app could be using a flashing alert as well as sound notification)
  • Cognitive : People suffering from concussion, ADD, dyslexia or autism (they’ll need to zoom in the content). A minimal design is well suited in this case because it will minimize distraction or cognitive load

It is also important to note that impairments are associated with temporalities, therefore a broken arm or concussion are considered as temporary impairments, blindness in considered a permanent impairment and being for example in a position where you can’t listen because of loud noise in your seroundings is considered as a situational impairment.

 

There is four types of impairments of the web: Visual, motor, hearing and cognitive.

 

Checklists: What makes an application accessible:

Accessibility is so broad and the user-ship is so diverse that a road map is needed in other to fully grasp it. The WCAG (Web Content Accessibility Guidelines) is a set of guidelines and best practices which had been put together by the experts to define accessibility in a methodical way.

WCAG is organized around four core principles:

  • Perceivable: Making sure users can perceive the content (sight, hearing or maybe touch)
  • Operable: Making sure users can use UI components and navigate the content (for instance avoiding to conceal crucial information in a hover effect because users using keyboards or screen readers might be deprived of it)
  • Understandable: Making sure users can understand the concept or the interface (Is the interface consistent enough to avoid confusion?)
  • Robust: Making sure the application is robust enough to be consumed by a wide variety of user agents and ensuring it works with assistive technology.

 

Conclusion:

Today, we looked into the definition of accessibility, we showed an example of inacessibility/accessibility, we looked at the diversity of impairments and we finished by looking into what makes an application accessible.

Do you have experience with accessibility? Please feel free to share your thoutghs with me.

Thank you.

 

resources: