☰ Navigate this post:
I happened upon and was impressed by Adrian Roselli’s post, “Dialog Focus in Screen Readers”. His testing set me a line of thought current to my consistent theme of questioning why we make our screen readers’ experience so difficult by design?
Adrian includes links to four posts on the topic by by Scott O’Hara from 2016 to 2019. The dates catch my attention. Are we discussing an acceptable web design pattern, or proliferating the ableism of yore? I replied to Adrian’s post with the following comment and set forward some thinking. I commented my understanding.
Reading Adrian’s and Scott’s posts I can understand that there must be a driving engineering reason for architecting these dialogs in the way they are. And in turn, why the dialog element is being promoted. Both reasons elude me.
Adrian’s CodePen dialog demonstration is used to test a variety of screen reader and operating systems I have no access to. And I am grateful to read his findings. In it, the dialog is characteristically included in the DOM outside of the main content and away from the actuated button interaction. Why?
I feel the answer is ableist visual design and engineering. When we approach the problem from an inclusive content-first perspective, we are only:
- Hiding or omitting content by default.
- Loading omitted content on demand.
- Presenting the content.
- Offering a means to escape or remove (close) the content and progress.
These intentions can be accomplished using already well supported inclusive design patterns, can’t they?
Consider expand and collapse or tabs and panels. They:
- Offer a transaction to access desired content.
- Enable the selection, availability, and and actioning of that content.
- Offer a means to close, remove, or at the least navigate from that content.
That’s a modal dialog right there?
As I commented on Adrian’s post, the dialog pattern under discussion seems to have evolved from an ableist pattern or expectation: from a time before screen reader users’ experience was considered. Here, WCAG seems intent on bolting in accessibility after the fact and again offers techniques to convert visual design into accessible content. That isn’t the same as presenting inclusive content.
I am convinced we can use more inclusive design patterns. First, let’s disassemble the dialog:
- We call the dialog.
- Where dynamic, we call the content into the dialog.
- We introduce a visual and mouse-proof barrier to prevent visual-led mouse interaction with the user interface behind the dialog and capture focus.
- The dialog is consumed and a means of escape offered. A Close button or navigation away.
Comparison with acceptable patterns
We can compare that list to the previous list for expand and collapse or tabs and panels. The difference is the barrier to interaction visually behind the dialog.
- A transaction that is vital to our users’ progress should always be available to the DOM.
- It is only hidden at run-time with CSS
- It is positioned proximal and semantically to the control in the DOM where it is expected to be.
Dynamically called and loaded dialog content or components:
- Don’t need CSS when the dialog is proximal to its initiating action.
With CSS switched off, orchestrating any dialog content to enter the DOM at the “bottom of the page” makes no semantic or cognitive sense, with or without scrolling to the new focus using accessibility adjuncts?
So why slave to doing exactly that?
Or am I only being naive?
It’s an Existing Pattern?
Go to WAI ARIA Practices Alert Dialog Example for a demonstration of this approach. And let’s rethink inclusive versus accessible, I thought.
Adrian kindly replied to my comment. At first, my confidence in anything accessibility was a little rocked. Perhaps it still is?
I recall in week 2 of the Masters UX Design program and a fellow student claiming accessibility is too expensive, resource hungary, and difficult. I retorted that it is a moral right and not so difficult when we design for it from the off. I still hold to that and the problems accessibility workers face seem to only escalate. More on that later.
There’s this moment in a 2012 Google developer’s video presented by the capable Racheal Shearer: watch her eyes and subconscious drop in demeanor when she demonstrates the gadget. The idea is to make a previously inaccessible Google button and dialog a triumph of ARIA. Alas, the moment is broken. Even the camera angle changes swiftly and far from covering her discomfort, it amplifies it.
She knows something isn’t right and can’t vocalise it because it totally destroys the whole aim of the video; 40-minutes into an otherwise confident and useful presentation. It’s devastating.
No one noticed, right? Sure, I cannot be the only one in 8 years? The incident builds quickly from 39 minutes and 30 seconds:
- Focus lands on widget. ChromeVox announces, “Navigation, Add to circles button”.
- Rachel presses Enter. Focus moves to the first of four checkboxes. ChromeVox announces, “Entering dialog.”
- Rachel says, “This is great. You can see that focus moved to that checkbox…you can move around with Tab to the other checkboxes.”
- Rachel presses the Tab key. ChromeVox announces, “Zero family. Checkbox not checked.”
On entering the dialog, the focus is already on the first check box combination and it isn’t announced. Rachel tabs forward and to her relief, the second checkbox combo is announced. She moves swiftly on and regains her composure. She summarises with, “…this is great! You can see that focus moved to that dialog and ChromeVox said, ‘entering dialog’…for someone who cannot see a screen, this interaction is perfect…“
In fact, this only highlights the points Adrian is making in his original post, and that we’ve just waited for 40 minutes to watch how technically brilliant Google was in 2012. Sorry Rachel, it happens to all of us.
I am reminded of my former surgical colleagues’ quip, “the deeper you stick your finger, the dirtier it gets”. I cleaned that up a touch. Also the motto, “do no harm”. I try to follow their diagnostic principles of treating root causes and not symptoms, too.
Given our moral duty to enable inclusive design and my excess of zeal to implement it from source, I am too often discouraged or stripped of confidence to profess any strategy to teams. The spiralling awareness of how disorganised the world of accessible is, is suffocating at times and that’s 30 years after first summarising any design as, “it depends”.
The root cause is the ableist advantages of design, engineering habit, and belief coupled with institutionalised priority to visual design in user experience thinking. With that thinking, why are we presenting a Boolean on and off dialog at all? Often it contains a decision with context to previous content. Why do we restrict or seek to control our users’ movement within it? Why must the background page be inert?
Of course I can recognise when existing content strategies may require that and what is it that creates that requirement? The first is a timeout message on a platform:
- We cannot know where in the presented content our user is.
- We cannot inject the message at that mystical point anyway without alerting that the message is there.
- The dialog content isn’t directly related to the page content or context.
So, of course there is a requirement for the dialog pattern; to play with focus and to notify each combination of browser, screen reader, and preference. I was naive to think we can work in a space without visual design (CSS) and to rely only on the semantic, text, and context of content in every circumstance.
Resolution and moving forward
Naivety of all circumstance aside, when we design a dialog to capture a data decision, we should still question its requirement. A navigation or list filter is not a dialog, for example. It’s a navigation or button made available to all.
In the following 2019 video, favourite accessibility whiz, Rob Dodson of A11ycasts runs through his take on the dialog. In it he confirms:
- There are dialog use cases.
- Dialog content should be truly hidden and not only displaced off the viewport.
- To leave focus available on the browser address bar to enable keyboard navigators to avoid malicious activity when trapped within the dialog.
Useful. I like that the short dialog content is announced. I do not like all the mentions of polyfils. That’s crazy talk given the investment in developing what can quickly become an outdated legacy component.
What isn’t useful is his bolting on his example dialog to an interaction that is clearly not a use case for a dialog. An Add To Basket button click does not need a confirmation? The Checkout button is the confirmation or opportunity to undo the action. And that set me thinking again. What are the use cases where we cannot design out a dialog?
Here’s the video, which is set to start at 5 minutes and 10 seconds when Rob makes his point about hiding rather than displacing dialog content.
So, what are the use cases where we must hide the dialog and its modal controls? That’s a great question and I will return to it. My intention is to investigate which can be designed out, and which cannot. Your comments will be useful.
In the meantime, Adrian Negger’s Modalz Modalz Modalz discovered via Scott O’Hara’s posts does a good job summarizing and building on my thoughts for alternative methods. For example, he asks, “have you considered the following?
- Non-modal dialogs
- Inline content
- Expanding elements
- A new page
- An Undo pattern (think Rob Dodson’s poor user case of a But Now button going to a Basket page)
Adrian Neggers’s Do’s and Don’ts.
- Make the dialog easy to close
- Give it a single purpose
- Keep it short
- Think accessible, accessible, accessible
- Modal inception: don’t open a modal from a modal.
- Present modals full-screen. That’s a new page.
- Present multi-step modals. (Some full page “modal” styles do this healthily and page to page).
- Self-spawn modals.
- Marketing modals. (Spotify! Looking at you, chum!)
In his YouTube video that follows, Zoltan Hawryluk uses an image for the HTML5
dialog Close button. This offers the opportunity to introduce the dialog’s context using the image alternative text. The dialog tag’s
aria-describedby lead the dialog’s semantic content to be announced, too.
Referring back to Adrian’s testing across screen readers, operating systems, and browser combinations I’d like to see how this fares. One observation I can make, and perhaps celebrate as a learning outcome from this post, is that the focus is fully trapped within the dialog. Our user cannot access the browser chrome or address bar. I know now that is bad.
As Adrian, Adrian, Rachel, and Rob remind us, screen reader users may navigate by any means and preference by focus or heading and visual users by their navigation tool of choice. So the core questions on when to deploy this troublesome dialog must be:
- Is it needed? Can we install the content inline with our users’ experience?
- Is the message or decision content in time with the experience of the page content?
- Do we need to prohibit access to the page content from the decision we are promoting? For example if required for review?
As with so many topics I choose to explore, it depends. Of course. And here’s the rub, in traditional user testing we are encouraged to find 80+ percent of usability problems by testing 5 people (a lore that is always misquoted). With accessibility, the range of Alternative Browser Technologies and user abilities seems to throw that metric out the window? We cannot possibly “test our users” of a banking or educational platform. Everybody needs access!
With Adrian Roselli’s observations on the corruption of the guidelines and techniques legislation are professing we follow through with WAI, we must make more noise. Of course I am frustrated! I want to do the best for all of our users inclusively and at most every turn I find with accessibility, “it depends” actually translates to, “so what?”
For the most part, accessibility is trailed behind visual design. We paint a pretty interface and then give hope everyone might access it regardless of the additional effort and degraded experience that offers. Perhaps banging my drum to equalise that status-quo is a place to start? And then I see people like Adrian and Scott banging the same drum for years and there’s essentially no great change.
There again, you gotta be in it to win it. Crack on.
Godfrey, P. (Year, Month Day). Title. Retrieved , from,