Forbidden designs: the "switcheroo"

When preparing for the IAAP CPACC exam, I came across a video where a speaker posited that an accessible version of a design could look exactly the same as a non-accessible version of a design.

I'd agree to a certain extent: I think that we can make designs more accessible by making certain markup choices. But after a design is fleshed out, there's only so much that we can do to make something accessible, and if accessibility is not considered from the start, a design may suffer other drawbacks when it is implemented.

In this series, I'll look at designs that I would recommend against implementing. Sometimes these designs inherently have accessibility issues; other times, implementing them will sacrifice on other things like performance and maintainability.

The design

We want to create a layout with a sidebar.

In large viewports, the sidebar will have a search box where a user can search for articles. The main area will have an article.

In narrow viewports, the search box should sit on top of the article.

I'm calling this design pattern the "switcheroo."

Approach 1: put sidebar last in source, rearrange in narrow viewports with CSS "order" property

See the Pen "Switcheroo": approach 1 by frankensteinke (@frankensteinke) on CodePen.

Pros

  • The code is clean, and we can achieve this design by updating only one CSS property.

Cons

  • This straight up fails WCAG 2.4.3, focus order. In small screens, my focus will hit the main article buttons/links (bottom of the page) before it hits the search box (top of the page).
  • This also fails WCAG 1.3.2, reading order. In small screens, the main article (bottom of the page) will be read before the search box (top of the page). This disconnect can be confusing for users of screen readers who are not blind.

Focus order

Wide viewports

Large viewports: elements in main area receive focus first

Narrow viewports

Small viewports: elements in the bottom article receive focus before the search bar at the top of the screen

Approach 2: put sidebar first in source, rearrange in wide viewports with CSS "order" property

See the Pen "Switcheroo": approach 2 by frankensteinke (@frankensteinke) on CodePen.

Pros

  • The code is clean, and we can achieve this design by updating only one CSS property.

Cons

  • This also up fails WCAG 2.4.3, focus order. In large screens, my focus will hit the search box (right of the page) before it hits the main article buttons/links (left of the page).
  • This also fails WCAG 1.3.2, reading order. In large screens, the search box (right of the page) will be read before the main article (left of the page). This disconnect can be confusing for users of screen readers who are not blind.

Focus order

Wide viewports

Large viewports: elements in sidebar receive focus first

Narrow viewports

Small viewports: elements in the search bar at the top of the screen receive focus before elements in the main article below it

Approach 3: duplicate HTML, flip "on" and "off" at breakpoint with CSS

See the Pen "Switcheroo": approach 3 by frankensteinke (@frankensteinke) on CodePen.

Pros

  • This no longer fails WCAG 2.4.3 or WCAG 1.3.2. Reading and focus order are logical in all viewport sizes.

Cons

  • The sidebar has to be duplicated twice in the HTML: once before the article, and once after the article. Extra CSS is required to toggle these on and off. This is worse for performance, and it also makes maintenance more complicated as any updates will have to be done in two places.
  • Things like form state are lost when transitioning between breakpoints. This could be fixed with JavaScript, but then it means performance suffers even more.

Maybe this can be fixed with reading-order?

In Solving the CSS layout and source order disconnect, Google's Rachel Andrew specifically calls out this type of layout ("[when] a different layout order makes sense at a certain breakpoint") and proposes reading-order and reading-order-items properties to fix it.

If implemented, this will let us keep the performance and maintenance benefits of approaches 1 and 2 without the accessibility drawbacks.

As of writing this article, reading-order has yet to have approved (let alone implemented by any browser), so I'd recommend staying away from this sort of design for now.

Tags