Share this:
Share

#CSSgrid, #Accessibility, #InclusiveWebDesign, #A11Y

By Miguel Estrada, UI Developer at SAP Customer Experience
Twitter: @developpeur

 

CSS Grid could create accessibility issues if not used with prudence, it gives great power over the User Interface (UI) layout but if we lose touch with the source order, then the User Experience (UX) could end up not making sense for users either with or without disabilities.

Web accessibility awareness is growing due to its costly consequences if omitted, more and more unwarily excluding users by overlooking their disabilities is becoming close to an act of discrimination. Besides the liability side, there’s also the fact that organizations could be missing out on revenue, audience and human resources by this omission.

As a UI Developer at the SAP CX Product Design team, part of my work is to test new layout implementation approaches for web applications, always keeping in mind the needs of our clients and their users, and with the clear mission of providing a comparable UX journey for users with and without disabilities.

Providing a comparable UX is not easy, it’s a challenge to balance visual order vs source order. The visual order is that in which the elements of a page are being visually rendered on the screen but may not necessarily correspond to the source order, the one in which those same elements appear in the code. Visual perception is two-dimensional and non-linear; the desired visual order is not always equivalent to the desired reading order.

Keyboard-only users could navigate (tab) their way through page elements and then finding themselves jumping from top to bottom of the page due to a reordered element being next in line in the source order. Worst if for some reason the tab order is altered with “tabindexpointing towards elements in a specific orderor when implementing group skipping.

This could grow in complexity when adding breaking points, as elements get reordered by screen sizes. Mobile assistive technologies like VoiceOver for iPhone (gesture-based screen reader) offers multiple ways to navigate a page either by heading, by links or by landmarks among other options.

Disconnection between visual order and source order is not a new topic, was already spotted with the “position: absolute” declaration a decade ago, same for Flexbox and now CSS grid. Although this is a known issue, unsurprisingly it is not well enough spread, as it is only when targeting Web Accessibility that this actually becomes “an issue” and because source-order independence is a wanted feature in CSS grid.

So, this article aims at bringing more awareness by spreading the word on the Accessibility Interference issue and is mainly aimed at Web Designers, UX Designers, Frontend/UI Developers and Product Owners looking for answers and suggestions on how deep to implement CSS grid or if even implement it at all (if Web Accessibility is their target).

Quick reminder: CSS grid does not replace Flexbox, they work on different dimensions. CSS grid is for ordering items in two dimensions: rows AND columns, whereas Flexbox is single-axis oriented: either rows OR columns.

css grid and flex box

Grid vs Flexbox

That said, it’s clear we need to resist the temptation of using CSS grid for placing just about everything on a page only because it’s possible… but let’s do that anyway for demo purposes. Let’s pretend we’re building an ecommerce storefront with CSS grid and we totally overlooked Web Accessibility.

 

For the purpose of this demonstration, let’s oversimplify the source code to the most basic elements of a generic storefront, and add “contenteditable” attributes to make all <div>focusable:

source order

Now let’s also pretend the design has had many revisions and that’s why the code ultimately ended up in the above order, because developers told designers: “Go crazy folks! Devs can reorder it, we have CSS grid powers” (not that this happens in real life). So, we get this visual order:

visual order

Link to the CodePen

The above is nowhere near close to the source order. For users without disabilities there’s nothing wrong with this picture since everything is a mouse-click away, no big deal. But now let’s empathize with a couple of UX personas with disabilities to see how they experience the user journey.

  • John: blind user, uses keyboard-only navigation, relies on a screen reader vocalization to know where he’s at, and to get to the next element in a UI.
    For John, reaching the search bar, navigation and product has priority, let’s not forget he can’t see which element comes next, this is a storefront, so let’s not delay him from checking out the product he’s looking for.
  • Jane: right-handed user, recently broke her right arm, has to use keyboard-only navigation, relies on her sight to know where she’s at, and for getting to the next element in a UI.
    Although Jane’s disability is temporary, and she can see which element comes next… oh wait! not quite, for her, all this jumping around the page is very annoying, she gives up and heads to the competitor’s storefront.

In conclusion, if you must use CSS grid in a project that targets Web Accessibility, my first suggestion would be to follow Inclusive Design Principles while designing the UX, the UI and while coding it, this will help reduce visual versus logical reordering scenarios by coming to realize your UX personas different situations and their context.

Other suggestions to improve Web Accessibility:

  • Start with a structured and accessible document, something that makes sense even without CSS.
  • Spot key elements that, when vocalized with a Screen Reader, make sense to the user journey.
  • Avoid reordering the visual order of the aforementioned key elements.
  • Limit the use of CSS grid to layout the structural areas (ex. header, aside, footer, main, etc.).
  • Avoid using CSS grid inside the structural areas to reorder elements within (like in the demo), but if you really must do this, then revisit the Inclusive Design Principles, cases vary, but chances are more empathy is needed.
  • Always come back to the source and check if the order still makes sense when aligned with the visual order.

Beginning and finishing with a well-structured document is the best way to start achieving Web Accessibility. Remember the document is the spoken representation of the website, that is, the order in which the elements on the UI will be vocalized by a screen reader and most likely by other assistive technology. The un-styled document should always make sense when read by humans and by assistive technologies.

I know, wouldn’t it be great if browsers had a way of figuring out and follow the visual order in a page instead of the source order? #Futurism?

Share this:
Share