In my feature request
at The Web We Want
I asked for a DOM order viewer
built into developer tools.
A screen reader, for example,
presents the page to a user
based on source order.
A layout that visually shuffles the content
can fail a WCAG review
under 1.3.2 Meaningful Sequence
and potentially 1.3.1 Info and Relationships.
Flex, grid, floats, absolute positioning,
and even table trickery
can all do this.
Except now we are more readily embracing
flex and grid as our overall layout tools.
Too often we assume we can test for something
falling out of order by tabbing through a screen.
The problem with that approach
is it only identifies interactive controls.
Under WCAG 2.4.3 Focus Order,
many developers are already comfortable testing this.
Interactive controls can be easily tested by tabbing.
Microsoft’s Accessibility Insights tool already shows tab order.
But non-interactive content is harder to test.
It is also harder to present
to stakeholders in a meaningful way.
This is not new stuff.
I first wrote about it in 2015.
Twice.
It came up in the W3C CSS Working Group
between my two posts
in response to a Mozilla hacks article
suggesting source order no longer mattered.
Which they quickly revised.
Those who work in accessibility
flagged this concern as well,
including Léonie Watson,
a blind screen reader user.
Alastair Campbell also raised it.
Rob Dodson raised it
in a 2017 Google Accessibility Cast.
Since then we have seen others
raise it in conference talks.
Manuel Matuzovic mentioned it
in his Dark Side of the Grid talk.
And Rachel Andrew referenced it in many of hers.
She recently wrote a post to remind
flex and grid evangelizers
that there is a real risk here.
The good news is that some tools are at least
making an effort to warn users.
even if it is hidden away
at the bottom of some general notes.
In 2017 Jen Simmons solicited feature requests
for the Firefox grid inspector
and said blog posts were acceptable.
So I wrote one.
And used it as a reference
to the feature request I filed.
Earlier this year
I filed it as a request with
Microsoft Accessibility Insights.
So that’s the background out of the way.
Now I want to demonstrate a
real case where a page uses
CSS grid to lay out two columns
of information.
As sighted users,
we will read the content horizontally
before moving to the next line
to get the intended meaning.
As a screen reader user,
it’s a very different experience.
This video is JAWS using Internet Explorer 11,
though the effect is the same
regardless of screen reader.
Now let’s say you want to find out the time
for the first coffee break.
Heading level 5 Day 1 dash May 16 clickable.
Heading level 4 8:30 dash 9:30 clickable.
Heading level 4 9:30 dash 9:45 clickable.
Heading level 4 9:45 dash 10:35 clickable.
Heading level 4 Keynote clickable.
Link graphic underline 2 underline NG dot PNG.
Heading level 4 10:35 dash 11:05 clickable.
Heading level 4 11:05 dash 11:45 clickable.
Heading level 4 Presentation clickable.
Ok, let’s skip ahead to 52 seconds.
Heading level 4 Keynote clickable
Link graphic 8 underline th 200 percent dot PNG.
Heading level 4 twenty hundred hours dash one o’clock clickable.
Graphic button underline 1 dot PNG clickable.
Headline level 5 day one dash May 16th clickable.
Day two dash May 17th button.
Heading level 4 Registration and Breakfast clickable.
Heading level 4 Opening clickable.
Heading level 4 link Typesetting for a Global Web.
Headline level 5 slash slash Hui Jing Chen.
Heading level 4 Coffee Break clickable.
Heading level 4 link The Challenges and Pitfalls of Server dash Side Rendering.
Heading level 5…
So that proved to be kind of useless.
I want to show you quickly
that could have been identified as a problem
using a bookmarklet I wrote.
No screen reader necessary.
This bookmarklet is a proof of concept
for the feature I have been requesting.
You provide it a selector for the parent container,
and then provide the display property.
It numbers each child
in the order they appear in the DOM.
You can visually see when something is amiss.
Use my other bookmarklet
and it focuses each one in order
to demonstrate the flow of the content.
Also, note that there were 30 other content
containers between the event time
and the name of the first break.
We can see it and easily count it.
That’s it.
That’s the feature I want
built into inspectors and testing tools.
Maybe a little more guidance would be swell
such as drawing arrows to show the flow,
as the Accessibility Insights tool
does with tab order.
Maybe also highlighting potential problems,
such as when on a left-to-right page
(such as English),
noting when a subsequent item in the flow
is both above and to the left
of the previous item.
If you have ideas,
corrections, code, fixes, whatever,
let me know.
If you are a tool maker and want my code,
let me know.
I am on the Twitters as aardrian —
a a r d r i a n
— or you can leave a comment on my blog.
All these links are available on my site at
Adrian Roselli dot com slash Smashing.
Or scan the QR code.
This video will be there as well
Even if this feature request goes nowhere,
I hope I’ve given you enough context
to understand some of the risks
of using layout techniques
without also considering the DOM order.
Thank you.