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 unwary retailers or content providers exclude their clients and users by overlooking their disabilities. This growing trend is becoming close to an act of discrimination. Besides the liability side, organizations could be missing out on revenue, audience and human resources by this omission.
As a UI Developer, 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. 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. However, it may not necessarily correspond to the source order. Being 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. Then finding themselves jumping from top to bottom of the page due to a reordered element being next in line in the source order. This gets worse if for some reason the tab order is altered with “tabindex”. Then pointing towards elements in a specific order when implementing group skipping.
This could grow in complexity when adding breaking points. When elements get reordered for many screen sizes. Mobile assistive technologies like VoiceOver for iPhone (gesture-based screen reader) offer multiple ways to navigate a page. Either by headings, by links or by landmarks among other options.
Visual order vs. Source Order
Disconnection between visual order and source order is not a new topic. It 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 there isn’t enough awareness about this matter. It is only when targeting Web Accessibility that this actually becomes “an issue”. Especially 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. It is mainly aimed at Web Designers, UX Designers, Frontend/UI Developers and Product Owners. If you are looking for answers and suggestions on how deep to implement CSS grid. Or if it’s worth implementing it at all (having Web Accessibility as 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.
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 e-commerce storefront with CSS grid and we totally overlooked Web Accessibility.
Source order matters
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:
Now let’s also pretend the design has had many revisions. That’s how the code ultimately ended up in the above order. Because developers told designers: “Ok, 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:
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. He 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.
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. It’s important 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, check for Accessibility at every step. 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 text in the document is the spoken representation of the website. Meaning, the order in which the elements on the UI will be vocalized. By screen reader software, and most likely by any 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 following the visual order in a page instead of the source order? #Futurism?