But I decided to finally get this post in a publishable state because I still see people asking questions about popover. Like, what is it? How does it differ from a dialog (modal or non)? Why doesn’t it do this one thing that I need it to? I’m not going to answer every question about popover. But I should get back into the habit of writing this stuff down once and pointing people to it, rather than providing repetitive one-off answers whenever I happen across someone asking about it.

Here we (finally) go.

Like a baked good, a popover rise

The popover attribute was initially proposed by Open UI. It does a lot for you in terms of not having to wrangle with CSS overflows or z-index clashes for your popover component. Additionally, it can provide some very handy basic focus management and dismissing behaviors. It even takes care of common accessibility mappings expected of popovers (again, read the article Hidde and I wrote).

But popover by itself doesn’t do everything you may need for fully accessible custom popovers. It wasn’t meant to, nor should it. There are variations in behavior for common popovers like menus or listboxes, sub-navigation lists of links, tooltips, teaching tips, info balloons, dropdowns (whatever the hell that means), light-dismissible dialogs, and [insert other made up terms for content that shows/hides while appearing atop other content].

The tldr; is that popover doesn’t do everything you might want it to, and that’s on purpose. Just like it’s on purpose that I’m going to be using specific quotes from Fight Club for the headings of this blog post - not every quote/heading. Just the ones that fit how I wanted to introduce new topics.

It’s only after we’ve lost everything we’re free to do anything

The popover attribute is a global attribute, meaning it can be used on any HTML element. That doesn’t mean you should. I mean, unless you want to create some broken crap.

Similarly to how the title and tabindex attributes are global attributes. If you put those on whatever you want without thinking of the UX / accessibility implications, then you’re likely making some janky web interfaces. Same with popover. Declaring the attribute on arbitrary containers, without understanding the actual experience you’re making for users, is unlikely to end well for users. Particularly because unless purposefully implemented to behave as expected (based on the visual representation / content of the popover) the popover will not come with all of the necessary accessibility semantics, or keyboard functionality users might expect.

To provide some context for the various reasons why more “automatic” accessibility semantics and keyboard functionality weren’t included, some background on the creation of the attribute is in order.

I am <popup>’s broken heart

The popover attribute wasn’t an attribute to start. There was a proposal for a <popup> element. However, when it came time to explain the semantics of the proposed element… well… it was like a non-modal dialog, but also it needed to behave like a tooltip, or popup pickers for comboboxes and menus. It could also be a popup list of sub-navigation links. But also, maybe it was even an element to be used as a generic container of content, so that content could simply be displayed above other content, without having to fight with overflow or z-index issues.

The <popup> element wasn’t just one thing, it was many ideas and potential use cases trying to be solved with a single element. Mind you, a single element that would not even necessarily be usable in all the contexts it could be needed, unless the HTML parser rules were changed to account for this new element. But, the level of effort to do that was not small. Nor did it help that identifying the exact semantics and a11y mappings for the element was like trying to nail mayonnaise to a rock with a deflated balloon hammer. Enjoy that mental image.

However, outside of defining the specific semantics of the element, a native “popup” HTML feature still made sense. None of the potential use cases nor initial rational for making it an element was “bad” by any means. There were a lot of very smart people working on this proposal that all had excellent intentions. But it did not have a clear path to get accepted as a new HTML element. It did not help its case that as an element, it would have required authors to specify the necessary ARIA roles to it for most use cases. HTML did not want or need another generic div or span element. Especially since that wouldn’t be accurate if it were to then also have these special popup behaviors.

So with the element pathway running too short for successful takeoff, <popup> was given a hard critique. In doing so, it was determined that what this “element” really represented was a collection of overlapping behaviors that many different types of web “popups” needed.

Accepting this shifted the proposal to defining a popup global attribute (which then had to be renamed to popover, because enough web developers out there figured “why should I have to validate my HTML by putting data- in front of my custom popup attribute? What could possibly go wrong aside from preventing the standardization of a potential popup attribute. LOL not my problem!”

That’s right - if one decides they don’t need to add data- in front of their custom attribute because why do that tiny bit of extra work, it increases the potential that a new attribute will need to be named after a breakfast food. Enjoy sounding like a weirdo when talking to your non-web dev friends when you tell them how you implemented the new pastry attribute into your project.

I am a global attribute’s complete lack of surprise

Back to popover as a global attribute… as mentioned there are a number of instances where one would want to display certain types of content atop other content of the page. For instance:

• a sidebar navigation that “slides out” (shows/hides) and overlays some content of the page
• or more simply, a sub-navigation list of links (a “drop down”) from a persistent navigation
• a custom tooltip so you can explain information that your design and content isn’t adequately relaying on its own
• teaching tips (non-modal dialogs) that should be positioned in the DOM near the content they are describing
• custom combobox and menu popups (listbox, dialog or grid roles for the former, and a menu role for the latter)
• and other examples, but this list is long enough!

There exist some HTML elements (e.g., nav, dialog, ul) that already provide the accessibility semantics we need to indicate to users the type of content they’d be interacting with. But, then there are all the other types of popups/popovers that (still) don’t have native HTML equivalents. Those would need to allow popover to be specified on things like div or custom elements (both role=generic by default) so that people could then use ARIA and additional scripting to build what they needed.

To allow for all the known instances of where popover could be useful, and so as to not prevent future legitimate use cases, it just made more sense to make popover global. Though as previously mentioned, while popover is a global attribute it doesn’t actually make sense to use it on all elements.

For instance, declaring popover on the body of your web page won’t do anything you’d probably want. That is, unless your goal was to make your entire web page hidden by default. In which case, good on you I guess?

But then there are the other elements like cite, s, blockquote, ruby, meta… take your pick really. The use cases for popover on those elements without any extra accessibility and UX considerations (or considering elements like meta are hidden by default - LOL) are rather dubious, IMO.

The point is that popover can be used on any HTML element, but the intent as with any HTML feature is that developers are using the attribute and element pairing because they have a good reason. And that they are doing what is necessary to make their popovers accessible. That is, beyond what the browser provides, since simply declaring popover on an element allows the browser to handle some of the (hard) work that needs doing. It’s on you to do the rest for your specific use case.

I am a popover’s medulla oblongata

The default behaviors for the popover attribute were chosen (I dare say carefully, and often with debate and compromise) based on the common overlapping behaviors amongst various different types of researched popups. As mentioned at the start of this post, there are existing articles written about those behaviors. So, outside of briefly mentioning them, I’m going to largely focus on the stuff that was purposefully left out, and might make people wonder why.

I am a popover’s overwhelming sense of inadequacy

Presently there are two types of popovers, with a 3rd - ‘hint’ - only available in Chromium browsers, at the time of this writing. I’m not going to talk about hint right now, other than to say it’s primary purpose will be to create hint-like popups - e.g., tooltips and maybe even browser error messages for form fields… maybe.

There is popover=manual which, outside of rendering the popover in the top layer and providing the necessary accessibility mappings / tab order updating between it and its invoking button element, all other behaviors are left up to the developer to implement.

Those other behaviors - if they are so desired, well they come with the auto state of popover (popover, popover="" and popover=auto). This is the type of popover that many people have veered towards, since it has additional light dismiss for mouse clicks outside of the popover and can be dismissed by use of the Escape key, and even TalkBack’s back gesture (in Chrome). For Escape key specifically, if keyboard focus is within the popover, focus will return to the invoking button - and if keyboard focus is outside of the popover, then it’ll simply close the popover.

For the third time now, you can read more about the accessibility of popover in that other post :)

I am a developer’s inflamed sense of rejection

There are a few things popover in any state doesn’t do, on purpose…

keyboard focus doesn’t automatically move to the popover when it is invoked

Well that is unless the element used to make the popover is a dialog. Not all popovers need focus to move to them when invoked - some of them (again think tooltips or toggle tips) typically shouldn’t receive focus at all, especially if they contain no focusable elements.

If you want focus to automatically move to your invoked popover, declare the autofocus attribute on the element that should receive immediate and initial focus. No jS solution, buddy!

Popovers do not auto-dismiss (light dismiss) when focus leaves them

People keep wondering about this. At one point this behavior was almost a default. But upon further review and as more people outside of Open UI got involved thoughts on this matter changed (IMO, for the better).

The light dismiss on focus out was identified as a concern due to that fact there are some popups on the web that do have an expectation for auto-dismiss behavior on focus out (e.g., listbox popups or menus). But since popups could be any type of element, e.g., non-modal dialogs or persistent popup-discloure widgets, that not all popovers should have this behavior, and that making it apply to all popovers could result in unneeded frustration for people using screen readers who might leave a popover without realizing. That could then fire a focus event on a new element outside of the popover, and then the content they were trying to review was hidden and they’d have to figure out why and re-locate the triggering element to reopen the popover and hopefully not repeat the unwanted behavior.

On the flip side, the light dismiss via mouse/pointer event was deemed less problematic, as though people could still accidentally dismiss by errant clicking, if those people can see the screen they’d be more likely to notice the dismissal of the popover.

Of course the “problem” with this default behavior is that some types of popovers (e.g, a select’s listbox popup and other form control ‘pickers’) do dismisses on focus leaving (hence why people should want to do this, when appropriate).

The short of it though is that adding focus-out dismissal is far more trivial than trying to prevent the auto-dismissing if it were the default behavior. Again, popover is not meant to solve for every behavior/problem one might have. I’ll be saying this a lot. It’s kind of the point of this whole thing.

Popovers are not f#&@ing modal dialogs

Well, at least not without some very specific effort to make sure you aren’t just making something that “looks” like it should be modal, but isn’t really. You know, one of the primary accessibility problems with many custom modal dialogs.

Maybe it was a mistake to have a ::backdrop for popover - it seemed like there could be some potential use cases at the time. But a popover even when used on a dialog element, is not modal. There are a bunch of truly unfortunate, I’d even say shitty, demos out there that might make you think otherwise.

A popover was never meant to be modal. There is already the dialog element which can be shown as modal - and with the command and commandfor attributes one will be able to invoke a modal dialog without needing a line of JavaScript.

Hopefully new features like command, and closedby for dialogs (which can be used to add outside click light dismiss for modal dialogs) will help people pick the right markup for the features they’re trying to create.

A popover can only be invoked by a button element

Declaratively, yes. Button elements (both button and input buttons) made the most sense as the initial element to support invoking a popover - because it’s the primary use case. Button make thing go show, or hide, or both.

A button also supports exposing an expanded and collapsed state, and as generic buttons don’t have any implicit behavior - declaratively marking up one to invoke a popover wouldn’t conflict with any existing behavior (which is why buttons in the submit state don’t work with popovers when used within a form element - because opening a popover and submitting a form have conflicting behavior).

This decision has resulted in some jibber jabber from those who want to make custom elements or div role=button triggers for popover elements. The current solution though is to use the Popover API if one is going to be creating custom components that are already using JS anyway to recreate button elements.

Remember, declaring an ARIA role only changes the exposed role semantics for an element - but does nothing to change the actual functionality of an element. So just like how <div role=image alt=foo> doesn’t work to provide alternative text to the faux image (because alt is not a supported attribute for div) neither is simply adding role=button to any old element actually a solution to make popovertarget work with that element. Doing so would fundamentally break the baseline that ARIA does not change the underlying behavior/semantics of an element.

However, there is talk about making popovers work with custom elements which have properly set elementInternals to expose them as buttons. More on that some other time… For now, if you have a use case for controlling a popover with an element that isn’t a button, you’re going to need a smidge of JS.

Tabbing order may be revised for popovers, but not the a11y tree

Something that is not always communicated in popover example posts, is that for most cases a popover and its invoking button should be siblings.

One of the goals of popover and it rendering in the browser’s top layer was because of the hacks people needed to perform with z-index and DOM placement, so that popups could be properly displayed above other content and not be clipped by overflowing containers.

Top layer rendering mitigates these issues, which means that one should be able to declare their invoking element and popovers like so:

<button popovertarget=foo>...</button>
<ul id=foo>...</ul>

The reality though is that even with top layer rendering, this ideal sibling markup isn’t always going to be possible. For instance, one cannot markup an HTML list within a paragraph. Not without the browser’s parser splitting that content apart.

So, per the following example, the tab focus reordering for popover is beneficial for keyboard users, as the hyperlink that would otherwise come between the invoking element and its popover is temporarily “skipped” when the popover is open - instead being the next tabbable element after the popover’s tabbable decendants.

<p>
  I am <button popovertarget=f>jack's</button>
  <a href=...>tabbing</a> popover example.
</p>
<div role="[whatever is appropriate]" popover id=f>
  <!-- static content -->
  <button>whatever i may be</button>
</div>

While browsers revise the tabbing order here so tabbing would go from the button in the paragraph, to the button in the dialog and then to the hyperlink, the accessibility tree is not altered. Someone using a screen reader’s virtual cursor navigation, instead of the tab key, would encounter the invoking button, the hyperlink (and any other content preceding the popover) and then the popover/its content.

Revising the a11y tree to mitigate this is not without performance costs, and is not something that one might want a browser to even do by default for all popovers. Rather, this was determined to be something that web authors should use aria-owns for when it would be appropriate to do so.

It’s called a changeover. The blog post goes on, and nobody in the audience has any idea

I’m not going to lie - one of the reasons I sat on this blog post for so long was because while I wanted to talk about the ins-outs of popover, I didn’t have a neat little way to package this all up to be like “and everything’s ok! All you have to do is X to make accessible popovers! HTML gives you everything for free!”

I don’t really care that I can’t do that, now. That’s not how this post is ending. Time to reiterate and restate.

The popover attribute isn’t meant to be the end-goal. It represents a collection of behaviors that can be used to make the basis of most types of popups - including the listbox popup for the customizable select element. But, it doesn’t do everything because it shouldn’t. There are still things that people will want to do with popover which will need JS (good thing there’s also a popover API!). There are still features that are missing from/would be nice to add to HTML, there are still components that need to be built - and be accessible - and popover isn’t going to magically make them all possible without extra effort.

But that’s not to say the book is closed on what popover and its related attributes (and now command attributes) should be able to do. New use cases can be proposed to extend current popover functionality. It’s a lot easier to add new good ideas than it is to remove bad ones (I’m looking at you details/summary and your allowance of nested input elements…). If those sorts of decisions get implemented, it puts the web into an awkward place. Behavior/allowances can’t be undone because then it would “break” the web - even if the current reality can still be broken for those with disabilities. We should want to avoid stuff like that.

But still, raise your issues. Make your requests. What else should popover reasonably be able to do? How should it be able to be controlled? And how will your proposal allow for a consistent accessible baseline? What is the line between a reasonable addition to popover’s functionality vs trying to make it into a different feature or element one might want?

I don’t have all the answers to such questions - though I got opinions (sorry not sorry). But, I’m hopeful things will keep improving. I know everyone in Open UI, and in the web standards groups that end up defining these features want to do the right thing by all users. All I know is that I just want people to be mindful about what they ask for, and to not think that a feature that was meant to be an ingredient should instead be the main course.

I am a paragraph.

I am also a paragraph.

• Even I am a paragraph.
• Though I'm a list item as well.

I might trick you

The above HTML-monologue is marked up as follows:

<p>I am a paragraph.</p>
<span>I am also a paragraph.</span>
<div>You might hate it, but I'm a paragraph too.</div>
<ul>
  <li>Even I am a paragraph.</li>
  <li>Though I'm a list item as well.</li>
</ul>
<p>I might trick you</p>
<address>Guess who? A paragraph!</address>

You may look at that markup and say “Hey! You can’t fool me, only the <p> elements are “real” paragraphs!

You might even call out such elements as divs or spans being used as “paragraphs” a WCAG failure.

But, if you’re thinking those sorts of things, then maybe you’re not aware that those are actually all “paragraphs”.

What you talking about, paragraph?

In HTML there is the the p element, which is the element you use if you want to explicitly markup text and other phrasing conetnt as a paragraph. But also in HTML, there is the more general concept/definition of paragraphs.

I’m not going to just copy over all the text of the spec, you can read it at your leisure. Especially if you haven’t already (don’t worry, lots of people - myself included - just start building stuff without reading the instructions first). But an example I want to highlight from the p element section is as follows:

List elements (in particular, ol and ul elements) cannot be children of p elements. When a sentence contains a bulleted list, therefore, one might wonder how it should be marked up.

For instance, this fantastic sentence has bullets relating to

• wizards,
• faster-than-light travel, and
• telepathy,

and is further discussed below.

The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list.

The markup for the above example could therefore be:

<p>For instance, this fantastic sentence has bullets relating to</p>
  <ul>
   <li>wizards,
   <li>faster-than-light travel, and
   <li>telepathy,
  </ul>
  <p>and is further discussed below.</p>

Authors wishing to conveniently style such "logical" paragraphs consisting of multiple "structural" paragraphs can use the div element instead of the p element.

Thus for instance the above example could become the following:

<div>For instance, this fantastic sentence has bullets relating to
<ul>
 <li>wizards,
 <li>faster-than-light travel, and
 <li>telepathy,
</ul>
and is further discussed below.</div>

This example still has five structural paragraphs, but now the author can style just the div instead of having to consider each part of the example separately.

Isn’t the p element important for screen readers?

Testing one’s assumptions is a good thing. Please, do it more and often.

Those examples I provided at the start of this post? macOS VoiceOver, NVDA, Narrator and JAWS treat them all as paragraphs (asterisks for NVDA, read on…)

With VoiceOver, you can use the VO + P (paragraph/plain text) or S (same item) keys to navigate to each of the “paragraphs”. Similarly with JAWS, the P hot key navigates to li, span, div and p paragraphs alike.

NVDA behaves similarly, but at least with the latest version with the default settings on, they have some special logic in place where only the paragraph that have punctuation (e.g., a period) in them will be navigable by the P hot key. Without punctuation, they’re not navigated to… which I can only assume is to try and distinguish between legit paragraphs of content, and small incidental text that might just be a nuisance to navigate through. But, that’s just a guess.

The point being that screen readers seem to be in step with HTML, at least from my understanding of what’s all going on here and actually testing how screen readers handle “paragraphs”. “Paragraphs” are more than just the p element. That’s not an opinion, it’s how they’ve been defined in HTML for years. That’s not to say people should not use the p element. It is absolutely the best practice when you need to define multiple blocks of paragraphs, rather than one div full of a bunch of text with br elements separating them. That’s just some sloppy slop. Writing explicitly semantic markup is often what people should aim for. It helps other developers understand your markup, it can be useful for styling, etc. etc. However, if you ever come across a “div paragraph” in the wild, and your WCAG trigger finger starts itching… It might just be worth remembering all this and just leave it be. Apply some Benadryl. If you’re worried about how screen readers will handle it, test before you declare something’s broken and then look silly when it’s not. Not every paragraph needs to be a p element with an implicit paragraph role.

Well, then why the ARIA paragraph role?

Oh damn it all… Fine, “good” question.

It’s a role largely meant for parity with HTML elements. A role actually ‘needed’ by most web developers, is rather suspect.

Similar to role=generic. Don’t use it.

Hell, if you even think you might want to try and get clever with it and do some things that HTML doesn’t allow, you’re probably setting yourself up for some foolishness.

For instance, ever thought it’d be nice to try and include non-phrasing content (think things like figures, tables) in a “paragraph”? (if so, need I remind you at this point of the HTML example I highlight above? but I digress..) You can’t do that with standard p elements, because the HTML parser - rightly - is like “what the hell you think you’re doing?” And the following markup…

<p>
  paragraph content goes here 
  <table><!-- table elements here --></table>
  more content goes here
  <ul><!-- list elements here --></ul>
  last line of content here
</p>

Gets rendered as:

<p>
 paragraph content goes here
</p>
<table><!-- table elements here --></table>
more content goes here
<ul><!-- list elements here --></ul>
last line of content here
<p></p> <!-- lol -->

Rare footage of the HTML parser at work...

Stop animated gif

But, what about ARIA? ARIA does what HTMLdon’t.

Why not try and get around the awkwardness of proton pack p-parsing, and do something like the following?

<div role=paragraph>
  p is for paragraph but that's not good enough for me
  <table><!-- table elements here --></table>
  i want a table inside of my gosh darn p
  <ul><!-- list elements here --></ul>
  maybe a list too, that'd fill me with some semantic glee,
  oh, paragraph is spelled 'd i v r o l e = p a r a g r a p h' 
</div>

Really rolls off the muppet’s tongue, doesn’t it?

The problem with the above, and the thinking behind it, is that it doesn’t do anything useful.

Where it works best, someone using a screen reader wouldn’t notice any difference to whether the role=paragraph was used, or if it was rendered as the parsed HTML of the prior example. The insertion of the tables, lists, whatever - those container elements are still not paragraphs, and thus they’d still result in a necessary distinction from the screen reader reading a string of text / phrasing content, to then encountering a block of content which is not just a string of text / phrasing content.

Additionally, just quickly testing with the latest versions/browsers of screen readers (available at the time of writing), some oddities with the above get introduced (maybe you saw that coming. Misusing ARIA to try n’ all). For instance, if specifically using paragraph navigation (the P hot key) JAWS would skip over the first line of the ‘paragraph’ and just start reading all the content of the table’s thead as a string, no table semantics to speak of. Or, if attempting to navigate by tables on with the iOS rotor, there’d be ‘none’ to find.

Again I will note that generally speaking, doing something like this doesn’t immediately impact someone’s ability to read the content. It’s when using specific screen reader commands that things could get a bit messy. Just repeating myself as I anticipate someone reading the above and being like “Scott says this breaks the internet!” and jeezy-creezy, I did not friggin say that…

Was there a point to all of this?

Yes.

Focus on markup issues/problems that actually have a detrimental impact on users. Futzing about whether to use a div or span vs a p element as the most semantic tag for content that is already covered under the umbrella of “paragraphs” is generally not one of them, in my opinion. Sigh… I just realized this entire blog post is just an elongated version of what I already covered in my post about divs from 2022. So much for being new and interesting?

Also, a reminder to test your assumptions. Don’t just assume the use of a div is a bad thing (see again my div post), or that you can slap-dash ARIA on whatever you want and somehow make it better without actually verifying that to be true or not. The over use of ARIA has taught LLM AI some pretty ridiculous bad practices that now need to be untaught. It’s annoying.

Also, also, I wanted to make silly 80s pop culture references, and the best way I can think to do that is through some snarky educational content. So I did.

After all, I ain’t charging for this shit. :)

The end.

Now, I could do what I usually do and write some long winded junk about what a spoiler is, how it’s essentially a glorified disclosure widget… maybe mention something about the details and summary elements and how they likely wouldn’t be sufficient for all use cases. Blah blah blah. Boring.

Instead, I’m just going to tell you what I’d expect from a spoiler component if someone were to build one, or if one were to ever be standardized. I’ll try to keep it as short as I possibly can (which I’m bad at).

Spoiler 1: there needs to be a semantic container element

While one obviously needs some sort of container to delineate the content that needs to be marked as spoilery - it can’t just be a plain old div. Insert your bewildered ‘gasps’ here.

Someone using a screen reader, for instance, needs to be able to know that they’ve entered a section of content that represents spoiler material, and also importantly, when they’ve reached the end of such content.

We should also be mindful to the fact that spoilers can represent an entire section of content, which could contain multiple paragraphs / structured content (e.g., lists n’ such). Or, it could be a string of text within a paragraph.

In lieu of a standardized element with a transparent content model (see how del and ins work / allow for otherwise ‘invalid’ nesting, if you aren’t sure what that term means), the spoiler container will need to be a custom element so we don’t need to switch between a div and a span (the latter being able to be used within a p element, where the former would cause the browser’s parser to kick it out).

<spoiler-component>
  ...
</spoiler-component>

As far as default accessibility semantics are concerned, a custom element is a long-winded way to write span or div, and that won’t cut it. So we need to give this thing a role and an accessible name to help define those boundaries I mentioned.

<spoiler-component aria-label="Spoiler" role="group">
  ...
</spoiler-component>

With this in place, we now have a wrapper to define the boundaries of the spoiler content. It will be exposed as a ‘group’ with the name of ‘spoiler’, identifying that any content within this group is spoiler-related. (please note that group might not be the ‘best’ role for this… but also, in my opinion there is presently no better role, so here we are)

Spoiler 2: there needs to be a way for it to be accessed by non-pointer (mouse) inputs

If you think that someone should be able to reveal the spoiler content by clicking anywhere on this element, then sure. That can happen. But, you can’t stop thinking there - sorry, I know thinking is hard.

We need a way for someone who isn’t using a pointer device (mouse, touch, etc.) to be able to reveal the spoiler content. So what are we to do? We add a keyboard accessible control to provide this function. You might have heard of “buttons”?

<spoiler-component aria-label="Spoiler" role="group">
  <button>Reveal Spoiler</button>
  ...
</spoiler-component>

Now we have a keyboard accessible way to reach this spoiler content. But also the visible button text helps identify why this blurred or blocked out content is presented this way. Cause you know… spoilery, content or ‘gated/potentially nsfw’ content can look similar in their visual treatment (visually obscured but still takes up space in the document flow). But they actually represent very different things… almost like just because some things look similar, you can’t just assume they’re the same… if this was Twitter, I’d be subtweeting really hard right now.

While we’re at it though, it should be a default that someone can show/hide (a.k.a., ‘toggle’ - it’s an industry term) the spoiler content. And that’s for a few reasons:

1. It might not be desired for the content to remain visible. We don’t know what the spoiler content could be, and maybe there’s something that gets displayed that one doesn’t always want to be displayed? Use your imagination… People should have a way to hide this content again if they want/need to.
2. If the button goes away when the spoiler content is shown, then we have to worry about focus management. Otherwise, as often happens when people don’t think about this, a screen reader’s virtual cursor could find itself sent back to the start of the web page, and that user would then need to re-navigate the page to find the content again - but this time without the ability to navigate to the button with the name of ‘spoiler’.
3. Keeping the button in place also allows us to provide a confirmation of action to the user by using an aria-expanded attribute. When first encountering the button, someone using a screen reader will hear the button is in the “collapsed” state. And activating it will announce it in an “expanded” state, thus signaling the button actually did what it was supposed to do, and now they can go spoil themselves.

<spoiler-component aria-label="Spoiler" role="group">
  <button aria-expanded="true|false">Reveal Spoiler</button>
  ...
</spoiler-component>

Spoiler 3: gotta actually hide the spoiler content to everyone

We can’t just blur, block or blot out the spoiler content (I don’t actually know what a blotting treatment would visually entail here, but it was a 3rd ‘b’ word for obscuring content, so I’m keeping it there. Why am I explaining this to you?).

There are two bits we need to consider here:

1. Visual styles alone won’t make the content actually hidden. Someone using their mouse could still copy the visually obscured content, or someone using a screen reader could still access the content. Additionally, if there are nested keyboard focusable elements within the spoiler, then those too could still be reached by someone navigating by keyboard. None of that’s what we want.
2. Since the “Spoiler” toggle button needs to be inside of the “Spoiler” group, we can’t blanket obscure everything within it.

So we can adjust the markup by adding a nested container as a sibling for the button. We can also use the inert attribute to serve as our styling hook, which also makes sure the content can’t be accessed when its obscured.

<spoiler-component aria-label="Spoiler" role="group">
  <button aria-expanded="false">Reveal Spoiler</button>
  <spoiler-content inert> <!-- look, it's inert! -->
    ...
  </spoiler-component>
</spoiler-content>

Spoiler 4: But howzitwork?

Well, I made a fancy-dancy (it is neither of those) CodePen to show you. The JavaScript is slapdash, the CSS is incredibly basic. I’m sure you can do better. Don’t @ me. I don’t care.

See the Pen Spoiler Component by Scott (@scottohara) on CodePen.

But you keep the button visible at all times!? I don’t want that!

Yup. I’m sorry you don’t want that. I don’t want to remove or hide it.

I’m sure a compromise can be made. But the button really should be persistently available so that people can toggle the content, and so that one doesn’t need to worry about moving focus when the button ‘disappears’ on them after activating.

Might someone decide to visually hide their button? Sure… I’m not going to fight ya on that, so long as it still works for all your users. But, if one were to standardize this, the default should be as accessible by default as possible. And that probably means the button should be persistent by default.

Wrap it up

A standardized accessible component like this could be useful for more than just temporarily hiding the key plot points of a [ insert thing you want to spoil here ]. Arguably it could be a useful component to have for interfaces that need to edit or present documents where content needs to be obscured.

Additinoally, a standardized component could provide a simplified aural UI in ways that are arguably a bit cumbersome for a web developer to deliver on.

For instance, rather than a group with the name of “spoiler” - a new variant of a group role could be created, with a localized role description (a.k.a., the ‘name’ of the role) of “spoiler” or “obscured” or something else… So instead of needing to name a generic group, you could just have an element that was announced with the name of that role.

There are other things that a browser implementation could consider - from exactly how to handle the inert content (making sure it can’t be found by the browser find feature), or even how it might handle the button part / focusability of the element in general. Maybe a browser-implementation could even go to the point of removing the spoiler/redacted content form the source code? I dunno about that… but you can’t really have truly redacted content on the web if you can just few source to check it out, can you?

My example is merely demonstrating a basic styled example of what I’d expect this to look like based on what can be done as a web author.

Ok, fun. This wasn’t too long, I guess.

We both have been involved in Open UI, and were involved in the creation of the popover attribute and API. You can read the version of the explainer I helped create (mostly the a11y bits), prior to its migration to the HTML specification - where I then helped edit/create the examples and author guidance for use of the attribute.

Hidde has been writing and giving talks about popover for quite awhile now (here’s another one of his popover posts from last year). He knew I had a lot I wanted to say about the attribute, but I had been struggling to collect all those things into a coherent post. What we wrote together largely covers many things I wanted to go over, but not everything. Hopefully I’ll get to at least some of those bits soon. I’m just glad we got what we did out the door. It was a post that was a long time coming (and that length of time is basically my fault). So, thank you Hidde.

The impetus for this addition stems from the “Consider creating an HTML search element” issue, filed on the HTML spec in late 2020, where the goal was to create feature parity between ARIA and HTML.

ARIA defines 8 landmark roles to help authors structure their web pages. For every landmark role, except for search, a native HTML element could be used - under certain conditions - to expose these landmark roles. BTW, I’ve written a few things about landmarks in the past. Here’s but one of them Accessible Landmarks.

With the addition of search, now every ARIA landmark has a native HTML equivalent. And also, now everyone who has ever written about ARIA landmarks needs to go update their articles. Have fun! (I’m going to update mine later. Don’t @ or DM me.)

How to use it

First and foremost, one would use the search element to expose the search landmark in the browser’s accessibility API, allowing people using assistive technology, such as screen readers, to discover this content area and allow for quick access to it. Being a “search” landmark, it implicitly indicates that the content one would find within would be related to searching for, or even filtering content (filtering is a ‘searching’ behavior… designers sure do like to use the magnify glass icon interchangeably between these UI controls, at least).

Very on the nose, but that’s the point.

Typically a search landmark will contain, at minimum, a text field (either identified as input type=text or type=search - read this if you’re wondering why one wouldn’t necessarily default to just type=search). Additionally, but not necessarily, a button to initiate the search would be another expected descendant of the landmark. Finally, other form controls, descriptive content or links related to understanding or modifying one’s search or filtering query could be present. E.g., checkboxes or radio buttons to modify the parameters.

Markup for a simple search where JavaScript is used to initiate the search functionality:

<search>
  <label for=s>Site</label>
  <input type=search id=s>
  <button>Go!</button>
</search>

Markup for a simple search where a traditional form submission is used for the search functionality:

<search>
  <form action="search.php">
    <label for="query">Find an article</label>
    <input id="query" name="q" type="search">
    <button type="submit">Go!</button>
  </form>
</search>

Some additional reduced markup search patterns can be found in the examples of the HTML spec element definition.

Why would I use this instead of form role=search

You might be looking at that second example, where a form element is nested within the search element and think “huh… a search element would still need a form? That seems like extra work to use two elements.”

And sure, that’s a valid takeaway. Two elements is more than one and you can identify a form element as a search landmark now by adding a role=search to it. But when has extra work ever stopped a web developer?

<div role=button tabindex=0>
  Sure i could use the button element,
  but F that noise.
</div>
<!-- F stands for "forget", obviously... -->
<script>
  /* 
    all the necessary keyboard interactions and behaviors 
    that now must be recreated to make an accessible "button" 
  */  
</script>
<style>
  /*
    all the styles for the default button state, disabled, 
    hovered, focused, high contrast mode styles, 
    anything else i'm currently forgetting...
    have fun recreating the wheel, yo :)
  */
</style>

But seriously, there was quite a bit of back and forth on whether the search element should be another type of form, but there was no appetite to do this from the browser implementers (for very reasonable reasons, mind you), and honestly, it is not that big of a deal.

The goal of the element proposal was to provide landmark parity with the available ARIA roles. The element achieves this, and everyone is still perfectly entitled to use <form role=search> for where that would be appropriate. But now, you also don’t have to use ARIA, which is also one of the driving principles of ARIA. As the ARIA spec mentions a few times (the following two quotes taken from different parts of the spec):

When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature.
…
When a feature in the host language with identical role semantics and values is available, and the author has no compelling reason to avoid using the host language feature, authors SHOULD use the host language features rather than repurpose other elements with WAI-ARIA.

So, for all you JavaScript developers out there who need to implement a search feature and should be exposing it as a landmark but have no practical use for native form behaviors, this one’s for you.

<search>...</search>
vs
<div role=search>...</div>

17 vs 23 characters. You’re welcome.

A final thought and thank you

To be brutally honest, this is not the most important element that’s ever been added to the HTML specification. It is however a nice little accessibility win. People don’t have to use ARIA to get this feature. It fills a little hole that has always been present, and every little bit helps.

Additionally, it was a very good experience getting to work on this with the HTML editors (primarily @domenic , who helped me with getting the PR done) and fellow ARIA working group member, Carolyn MacLeod who originally made the proposal to HTML to add this element. Further discussing this new element with browser implementers, and identifying a need for some HTML parsing updates (which will be important with other new features coming to HTML) was an interesting, related bit to this process. Maybe more on that another time.

Also, if you’re interested in getting involved with working on the ARIA specification, here’s a nice and easy entry issue to reference the new search element to get you going: ARIA issue #1898 - Add base concept for search role.

But finally, Carolyn unfortunately passed away in February of 2022. This was the last thing I was able to work on with her. Again, while not the biggest win for the accessibility community, I know seeing what she started finally get merged into the spec would have made her happy.

So, I’m really glad this element is now part of HTML, and will soon be available for people to use to markup their web pages. Thanks Carolyn for helping to make this happen.

This will retread and extend on my previous Inclusively Hidden post. Specifically the parts about “visually hidden” content.

But in lieu of reading that, the reasons one would visually hide content in the development of a website or web application is generally to include extra content for accessibility. For instance, to mitigate against specific design choices, where visually something may be apparent, but programmatically not so much. Or, portions of UI are only need to be visible when needed, but otherwise they need to be hidden but remain accessible so that those using keyboard or assistive technology can find them.

The way to visually hide content, but keep it programmatically available, that is probably the most familiar to many developers is with the following CSS ruleset, or a variation of it:

/* sometimes referred to as .sr-only */
.visually-hidden:not(:focus):not(:active):not(:focus-within) {
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

For a breakdown of what each CSS property is doing, check out this dissection of the ruleset, by TPGi. Tbh, depending on your browser support matrix, I’ve found that there a few property declarations that can be removed with no negative impact for modern browsers/screen readers. Just something to think about. Maybe test this out n’ see if you can find something broken? I’m presently unaware of issues - so long as this is being used to just visually hide static content. As in, this ruleset is not intended to hide interactive controls. But just static content, or static content within an interactive control.

At the end of that TPGi article, the idea of consolidating this ruleset into a single CSS declaration, for example display: visually-hidden, was mentioned. This idea was also a brought up in “The Web Needs a Native .visually-hidden”, by Ben Myers. However, this is not a new idea, and has been brought up over the years. For instance, as a request for an HTML feature, and as different CSS WG issues from 2016.

Full disclosure, I have frequently used and have recommended the use of visually hidden content. It’s an important tool that we presently need to help mitigate accessibility gaps for content (design) as well as features of and related to common web UI. However, while a frequent recommendation, it’s one I would rather never recommend again. But, before we get into that and why I find the idea of the technique becoming any sort of web ‘standard’ rather icky, let’s review some situations where this ruleset is commonly used.

Examples of visually hiding content

Often, one will need a skip to main content link on their website or web application in order to adhere to WCAG’s 2.4.1 Bypass Block. The most common way of implementing this instance of a skip link is to visually hide it until it receives keyboard focus. One needs to be able to see what they’ve focused to know whether or not to try and interact with it. A skip link is a navigational mechanism primarily for a sighted keyboard user, after all.

Not all news websites have a skip to main content link, but NPR.org does. They have a couple visually hidden skip links that become visible when they receive keyboard focus.

NPR uses a variation of the visually hidden class.

Or, one might visually hide pesky form controls so that they are still available to screen reader and keyboard users. But maybe you wanted to replace them with a fancy ‘custom’ control(s), allowing for more styling options.

Visually styled to look like stars and a cancel icon, these are all native HTML radio buttons and would be exposed as such if styles were turned off or blocked.

Fun fact: these radio buttons don't use the 'typical' visually hidden class, either.

Alternatively, maybe you don’t need to restyle a control, but only want it available on hover and focus. That’s a thing we do to make it more difficult for sighted touch, switch device and speech recognition users to find initially hidden controls. I mean, to visually declutter UI.

But snark aside, there is a constant push and pull between overloading UI with too many controls or too much content. If the UI has too many competing visual features at one time, it can be overwhelming for some users. However, hiding important UI can result in higher difficulty for other users to interact with the page. The struggle is real.

Each line of code can be commented on with a GitHub pull request. It would be overwhelmingly to visually display the a comment button on each line, so it is visually hidden until the line is hovered, or a specific one of the buttons receives keyboard focus.

These buttons also don't use the typical visually hidden class.

Or or, content might need to be visually hidden because someone wrote some rubbish call-to-action copy and the web page would otherwise be riddled with “learn more” or “read more” links that have no immediate programmatic context to their purpose.

Maybe a web app was designed in a way where one can infer the current page’s purpose due to the styling of the “current page link” in the primary nav - so there’s no visible heading to introduce the primary content of the page. Oh, and adding that heading in there would “degrade the design”, so cool. Guess we can insert a visually hidden heading to help screen reader users, at least, without disrupting the design which would be absolutely ruined and unusable if a heading was added. Horrible, horrible headings…

Rather than display the primary heading of the page, Facebook visually hides it.

The visually hidden technique appears to be used here, but has been obfuscated into various single-purpose compiled classes. .x1heor9g is a real banger of a utility class name, if I do say so myself.

Or or or, a website or web app requires a ‘global’ live region component. For instance, rather than having multiple live regions on a web page, a single live region is used to expose any dynamic updates that occur on the page. Live regions can be quite annoying to get right, so a persistent visually hidden live region is often used, waiting in anticipation for the momement they can inform screen reader users that “You must fill out your name. It is REQUIRED!!!! SURE I KNOW YOU’RE JUST TABBING THROUGH THE PAGE RIGHT NOW TO CHECK OUT WHAT THIS FORM INCLUDES, BUT DAMNIT I NEED YOUR NAME! I NEED IT NOW!!!! NOW!!!!!” I may have some thoughts about how aggressive many people have made web forms, with their basic on-blur error messaging logic.

The most on the nose instance of the .sr-only class, being used to visually hide a global ARIA live region as the last element in a web page.

There are other instances of where you may want content to be hidden but available only for people using assistive technology, or only when the hidden content is actually relevant (e.g., a sub-navigation list of links). These would be different from the previously mentioned examples, as these would not be situations where the content should be treated as visually hidden. Rather, they would generally need to be hidden to everyone. Again, see my previous blog post for more information on stuff like that.

Sure does seem we need to visually hide stuff quite a bit?

If there’s a need for so many instances of visually hidden content, why wouldn’t it be standardized? Well, I mean standardized beyond the already existing ways to visually hide content:

• color: transparent
• opacity: 0
• transform: scale(0)
• clip-path: inset(50%)
• etc.

By themselves, each of these properties can be used to visually hide content per the situation, but someone might have to add a few extra property declarations, e.g., position: absolute, to get the content to no longer take up visual space in the document layout. Or, a combination of some of the above or other properties may be necessary to fit one’s exact visually-hidden needs. For instance, if creating a custom checkbox style, one might think to just use the standard visually hidden class.

However, as I've been noting for some time now and others have since mentioned, using the standard visually hidden class will introduce problems due to the 1px by 1px nature of the beast/ruleset.

Remember, not all screen reader users are completely blind. Some of these users, for instance, might be able to see or partially see a custom checkbox on their iOS or Android device. They might then think to try and press or drag their finger across their screen to “explore by touch” while the screen reader is enabled. However, they’d then be seemingly unable find this checkbox that visually appears to be there, but is really shoved off into a 1px by 1px square somewhere on the page, if not entirely positioned off screen. Fun! Good luck finding that 1px by 1px checkbox that might not even be discoverable in the viewport.

Heck, this problem would exist even for instances of not completely restyling a checkbox from the ground up (which also, unless you're going way out there with a custom style, we don't really need to do anymore.

Consider a button (such as a “more options”, or “edit”, “delete”, etc.) that is visually hidden in a ‘card’ or ‘row’ of content, where it only becomes visible on hover (generally of the whole container), or focus/focus-within the container. If the standard visually hidden class was used here, this too would suffer from the 1px by 1px problem. (You may remember I mentioned GitHub has a visually hidden comment button for reviewing PRs, but it doesn’t use the standard visually hidden technique. They don’t have this 1px by 1px problem!)

A standardization of the ruleset wouldn’t help with these situations. Actually, it’d probably make the problem more prevalent, since many developers would (understandably) think all they needed to do was to set this fabled single property, and all their accessibility problems concerning content that needed to be hidden would go away. Just like ARIA, it’s there to make your content more accessible.

Wait… what? ARIA gets used in situations where it is either unnecessary or not appropriate for the use case? Shocking.

What about fixing the underlying problems instead?

Getting caught up in how to make visually hiding content easier for developers to implement (you know, so they don’t have to copy/paste a class name), imo, is missing the mark on solving the real issue. We “need” to visually hide content because of gaps in the design of the UI, or because of features which are lacking from browsers.

For many of the examples called out earlier, what if those gaps were solved instead?

Skip to content links are also a dirty hack

We shouldn’t need skip to content links. Rather, what would be way more useful that including a visually hidden link at the top of every website, is if browsers would support navigation by elements that are exposed as landmark roles. At the very least, allow for a mechanism to directly move focus to the content of the main element/landmark. Alternatively, allowing for quick navigation by headings would be pretty awesome, too.

Implementing one of those ideas could negate the need for skip to main content links, at least. You don’t need to visually hide something that isn’t necessary to implement, after all.

Styling form controls isn’t as bad as it used to be

Yes, visually hiding a form control so that a custom styled ‘faux’ control can be rendered in its place is rather common. But as mentioned, the standard visually hidden ruleset is not what you should be using to effectively hide the few controls that even allow for this hack. Also, wouldn’t it be far better if time was instead spent trying to push proposals like a new checkbox element over the line?

IMO, new checkbox and radio elements are not the most important features we need on the web. But if given the option between those and a standardized visually hidden feature, yes. Please. New checkboxes and radios. Solve for the problem, not the symptom.

Regarding aria-label and insufficient CTAs

A web page containing a bunch of buttons or links with, for example, “edit” or “learn more” visible text, and thus accessible names, can be rather rubbish depending on the way one is navigating the web page.

For instance, a page listing article or product previews, each with with a “learn more” call to action link. Without extra development effort, all these links will simply be exposed as “learn more” when someone navigates by focusable elements, or uses their screen reader to navigable specifically by links.

Code for what could produce the above link listing might look something like this:

<div class="card-or-whatever">
  <h3>Here's some descriptive text but lol, I'm not a link!</h3>
  <p>Fluffy fluff fluff tells you stuff about the fluff.</p>
  <p><a href=...>Learn more!</a></p>
</div>

In these contexts where the link serves as a standalone CTA outro to UI elements like ‘cards’, these can be flagged as 2.4.4 Link Purpose (In Context) failures. This is because the CTA is not programmatically associated with other text (e.g., a paragraph) to help provide the context as to what one would be learning more about.

This is why such CTAs are commonly recommended to use the visually-hidden technique to provide more context. For instance,

<a href=...>
  Learn more
  <span class=visually-hidden>about whatever yada yada</span>
</a>

However, while often used to alleviate this lack of context, there are other avenues we could be considering, instead.

For example, aria-label and aria-labelledby can allow for the same context to be provided, without the need for the visually hidden hack.

<a href="..." aria-label="Learn more about something">
  Learn more
</a>

...

<p id=thing>My address, or whatever</p>
...
<button id=self aria-labelledby="self thing">
  Edit
</button>

Granted, right now translation services and aria-label continue to have issues, and using aria-labelledby has the problem that it necessitates the use of IDs, and developers hate IDs.

So, maybe ARIA isn’t an option for you. But you know what that leaves? Making a better design.

For instance, I’ve already referenced the Nielsen Group article “Learn More” Links: You Can Do Better, but I will do so again because it is worth repeating.

Take a look at many popular news aggregate websites (well, look at them just in the context of this train of thought… I can’t endorse them otherwise, unless you’re looking to significantly up your anxiety and tank your mood. News sites do that great.). Many of which I’ve reviewed show they’ve since moved away from the “learn/read more” CTA approach and instead treat the concise but descriptive titles/headings of their article previews as the links to their content.

“But Scott, user testing has shown that CTAs get more clicks”

Well sure, I didn’t think we needed a test to determine if someone sees a big button-looking control that screams “click me”, they will click it. But visual cues to visually promote “click me” behaviors don’t “need” to impact the accessibility of the content.

For instance, there’s no reason one couldn’t implement a CTA as more of a decorative element that still allowed for pointer events to activate it. A very quick example (and one of the demos even still has the lovely ‘read more’ appear on hover/focus):

See the Pen simple cta article 'card' by Scott (@scottohara) on CodePen.

I’m sure many could come up with more creative designs than that five minute codepen. But maybe take this as a challenge. Accessible design doesn’t need to be boring, rather good accessible design demands creativity. So, be creative and move away from the uninspiring learn more links and visually hidden hack.

We need a notification API

Live regions are finicky, and having to implement a visually hidden live region to act as a notification center for a website/web application is yet another hack built atop a shouty house of cards.

Rather, if we had a notification API, we wouldn’t need to visually hide live regions at all. Rather, we would be able to dynamically render the content we want on our web pages, and then use the API to ensure the rendered text content, or maybe even something more concise/informative than what is visually rendered, could be exposed to the accessibility tree. No reliance on DOM elements, no problems where the live region that should have handled this is within an inert or aria-hidden=true subtree because a modal dialog opened and blew your aforementioned shouty house of cards down.

<dialog>
  Imma be a modal dialog!

  <button>
  	Press me and make a toast show up,
  	but LOL don't expect to hear it!
  </button>
</dialog>

...

<div class=visually-hidden aria-live=polite>
  Inject whatever you want into me, and I'll typically
  announce it. But, I'm not saying 
  "boo" if that modal dialog is open! 
</div>

You want to get around this? Either don’t use the native dialog element (which would be quite a shame, as using it responsibly can be far better than creating your own). Or, put another live region into your dialog, so your page can continue to shout things while the modal dialog is open and everything outside of it is treated as inert.

Wrapping up

For better and worse, we will have instances where we need to visually hide content to mitigage a gap in the visual design. That’s not to say that every gap is necessarily due to a failure to incorporate accessibility in the design process. Rather, because there is a balance that needs to be maintained between what is visually presented, vs what is programmatically conveyed, sometimes the best way to work around that is to inject content that is specifically for people using assistive technology.

Them’s the breaks.

But, as I’ve hopefully illustrated by now, while there is a common ruleset for visually hiding content, codifying that to me seems more of a silent acknowledgement that a hack is the best we can do. I don’t agree. The web should be better than that.

• We should be able to navigate to landmarks (e.g., skip to main content) by default browser commands.
• We should be able to send dynamic messages to assistive technology, without having to rely on fragile, invisible, live regions.
• We should be able to use aria-label (and also aria-description) without having to worry about translation services.
• We should be able to fully and easily style common form controls.
• And we shouldn’t need to introduce a native way to do all these things, which covers various use cases for visually hidden content, but not all of them.

Introducing a native mechanism to save developers the trouble of having to use a wildly available CSS ruleset doesn’t solve any of those underlying issues. It just further pushes them under the rug. Additionally, it introduces an “official” way to hide content which at best, might not be the right way to hide content for a particular use case. And at worse, it provides a hiding mechanism for people to misuse. Content that should be hidden to everyone could get the “well, isn’t it more accessible if we never truly hide content, so that screen reader users can always have access to everything at all times?”

No. That’d be quite problematic. And while paraphrased, that is a question I’ve been asked, when having to mention to someone that they’ve incorrectly hidden content. While this thinking comes from a good place, it is exactly what we don’t want to happen.

Now, one might say that education and examples are the ways to promote correct usage. And that person would be right. But also, if documentation and providing official examples would mitigate misuse and misunderstandings, then we wouldn’t need stack overflow or slack channels for people to post questions, daily, or online courses to explain to developers what existing free resources already cover.

Anyway, that’s it. Those are my very not-hidden thoughts on the topic. Thanks for reading all these yucky words. So so many words…

But as a quick a reminder, ChatGPT’s responses are derived from interpreting the question it was asked, and crafting its response based on what it has ‘learned’ from us, via what we’ve published to the Internet. In regards to how accurate it’s responses are to accessibility related questions, they may be rather high level and “accurate”, but can also quickly veer into laughably (depressingly) incorrect territory. The accuracy of what you get back will also be contingent on how you ask your question. For example, if it’s too broad then you’ll likely get a broad response back. If it’s a very focused, but potentially leading, question then you could very well get a response back that is biased to your ask.

In my previous post, I had asked a very high level question on how to make an accessible button for my web page. For something that should be so simple, there was a lot of inaccurate (i.e., wrong or u) information returned.

So what do we get back if you ask about something more complex? Something that has a long history of developer pain points and accessibility quirks and gaps with custom implementations? Something that, for all its past troubles, has finally reached a point of being rather straight forward to implement and the browser takes care of the majority of its accessibility requirements for you?

Having an AI dialog

If this is your first time coming to my blog, hi. I’m Scott. I’ve spent too much time working with and talking about the accessibility of web dialogs. However, today I don’t have anything specifically new about dialogs that I want to go over. Go read this if you want my latest take on the dialog element. Instead, I’m very curious to see what ChatGPT has to say about something that has such a long history of being inadequately implemented, in regards to accessibility, by web developers.

The purpose of this will be to demonstrate what ChatGPT gets right (because to be fair, it does get some stuff right), vs what it gets wrong. And boy howdy to that…

What is a web dialog?

So I asked ChatGPT what a web dialog is. Seems we should setup some level of a baseline.

I included the word ‘web’ because otherwise it would have given a high level response about what a conversation between two people is, as well as a brief mention of a dialog also being a GUI element for web and desktop applications.

A web dialog, also known as a modal or a lightbox, is a user interface component that appears on top of the current webpage, typically as a pop-up window or box. These dialogs are designed to provide additional information, options or controls for the user, and can include text, images, forms, and other interactive elements. Web dialogs are often used to display login forms, subscription forms, confirmations, alerts, and other types of interactions, that are not part of the main content of the webpage. Examples of web dialogs include a pop-up window that appears when you try to leave a webpage, a subscription form that appears as a pop-up after clicking on a sign-up button.

So this is both an example of what ChatGPT can do well, as well as an example of “neat, I got a search result without any author attribution by typing into a chat interface”. Nothing inaccurate here. Also nothing anyone specifically needed ChatGPT for.

So let’s move onto something more specific to web accessibility.

QUESTION: how can I create an accessible web dialog?

The following are two different responses that ChatGPT gave me to the same question during two different sessions.

First Answer

There are a few best practices you should follow when creating an accessible web dialog:

1. Use clear and descriptive labels: Make sure that all buttons and controls within the dialog are labeled clearly and accurately. This will help users understand what they are interacting with and what actions they can take.
2. Provide clear instructions: Provide clear instructions on how to interact with the dialog, such as how to close it or move between different options.
3. Use ARIA roles: ARIA (Accessible Rich Internet Applications) roles can be used to provide additional information about the dialog to assistive technology, such as screen readers. You can use roles such as “dialog” and “alertdialog” to indicate that the content is a dialog and to let users know that they need to take action.
4. Create a contrast of colors: Make sure that the contrast between the text and background colors is high enough for users with low vision to read the content.
5. Use a “modal” dialog: A modal dialog is a dialog that requires the user’s attention before they can continue to interact with the rest of the website. It prevents users from interacting with the rest of the website while the dialog is open.
6. Make the dialog keyboard-navigable: When creating a dialog, make sure that users can also interact with it using just their keyboard. This way, users who use assistive technology, such as screen readers, can still access the dialog and interact with its controls.
7. Test for accessibility: After creating the dialog, test it using assistive technology to make sure that it is accessible for all users. By following these guidelines, you can create an accessible web dialog that can be used by all users, regardless of their abilities.

Breakdown of First Answer

1. The initial item in the returned list of best practices is spot on. It’s high level, but my original ask was rather high level as well.
2. The second point seems OK at first glance, but then when it tries to clarify about what sort of clear instructions are needed, it immediately gets into some odd advice. Can you think of a web dialog you’ve interacted with where there was text provided informing you that to close the dialog you can press the “close” button, or use the Esc key? Or how to move to the different interactive elements within the dialog? Hopefully most people would know to interpret this as it should have been stated “provide clear and consicse instructions on how to interact with the content of the dialog, as necessary”. One does not need instructions on how to perform basic tasks, unless this is some nightmare dialog from hell where up is down, left is red and close buttons within it shoot laser beams and hurl crackers at napping cats. If your dialog does those things, go ahead and provide instructions. Please.
3. Regarding “use ARIA roles… ‘dialog’ and ‘alertdialog’…” nothing wrong with that on its surface, except for the fact that it doesn’t indicate when to use which role (probably a more clarifying question one could ask) - but it also fails to mention that you don’t need to use ARIA at all. Just use the dialog element (reasonably).
4. I chuckled a little bit at “create a contrast of colors”, but outside of the initial odd wording, it’s not wrong. It’s also advice that goes beyond specifically a dialog. But hey, doesn’t hurt to remind people to always be contrasting (their colors).
5. Huh… using a modal dialog is only a best practice if you actually want a modal dialog though. Would someone know to ask for clarity on what this means and how it differs from ‘use ARIA roles… ‘dialog’ and ‘alertdialog’? I hope so.
6. A mixing of information here. Being keyboard-navigable is important to people who have full vision, low vision, or who are blind. That aside, again this is a more global concept that is not unique to dialogs.
7. As mentioned in my previous post, testing using assistive technology may be a big ask for someone who is unfamiliar with assistive technology, or who might be aware of it but has no idea how to actually use it.

By following these guidelines, you can create an accessible web dialog that can be used by all users, regardless of their abilities.

But hey, if you follow these guidelines then you can rest assured that whether someone can whistle or not, they can use a dialog. Oh, wait. No, it probably means that a dialog can be used by people with disabilities. Yeah, that’ll all come down to the implementation. But before we get to how ChatGPT says to do that, let’s look at what it also said when asked the same question during another session.

Second Answer

There are several ways to make a web dialog accessible, which will provide a better user experience for everyone, including users with disabilities. Here are a few important things to keep in mind when designing an accessible web dialog:

1. Provide a descriptive title: The title of the dialog should be meaningful and accurately describe the purpose of the dialog.
2. Make sure the dialog is keyboard accessible: Make sure that users can operate the dialog using just a keyboard and that there are no keyboard traps.
3. Close the dialog with the Escape key: This is a commonly understood key for closing dialogs.
4. Make sure the dialog is screen-reader friendly: Use proper ARIA roles, labels and attributes to make the dialog accessible to screen readers.
5. Focus management: Ensure that the focus is moved to the dialog when it opens and is restored to the triggering element when the dialog closes.
6. Provide a clear and visible dismissal button: A close button should be visible and easily located.
7. Take care of accessibility in form controls: If the dialog contains any form controls, ensure they are labeled and can be filled in by assistive technologies.
8. Creating an accessible web dialog takes a bit of extra effort, but it is worth it in the end. By doing so, you can make your website more user-friendly and accessible to people with disabilities.

I’m not going to break this response down, but I will acknowledge that outside of a few nits it is a far better response than the first. Kinda like it’s a different person on call for the help desk. I can buy that, not everyone who is an accessibility practitioner knows everything about accessibility. Some people know more about accessible UX concepts, some others about legal compliance, and while others may know about technical implementations. Any one of those people might give you a variation on a response, and include their own opinionated or even inaccurate information to boot as they try to smooth over gaps in what they know they should cover.

I mean, people shouldn’t necessary do that - smooth over the gaps. But, when one has to take on the role of being the expert in a room full of people that don’t know a div from a button, there is a lot of pressure to know the answer. I wonder how much better off web accessibility would be if people instead said “huh, I don’t know. Let’s do some testing and find out!” - rather than “screen reader users will be confused and WCAG is going to steal your lunch and step on it if you don’t make that link into a button”.

OK, maybe that’s not an entirely accurate representation of what people say. WCAG is far more partial to breakfast items…

Anyway, high level guidance aside, people have expressed that they want ChatGPT to give them recommendations for how to write accessible components. And some people have indicated that they think ChatGPT can do just that. So…

How do I build a c between two people GUI ARIA role lightbox thing, modal?

Asking ChatGPT how to code an ‘accessible dialog’, or ‘accessible web dialog’, will return variations on the same sort of answer each time you ask. The following show two wildly different responses, each with their own issues.

Note: I have left out the example JavaScript and CSS that was returned for each. Reviewing them wouldn’t yield any more important insights, and this is already getting too long.

First Answer to “show me the code for an accessible dialog”

Here is an example of the code for an accessible dialog:

<div class="modal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-hidden="true">  
  <div class="modal-dialog" role="document">  
    <div class="modal-content">  
      <div class="modal-header">  
        <h5 class="modal-title" id="exampleModalLabel">Modal title</h5>  
        <button type="button" class="close" data-dismiss="modal" aria-label="Close">  
          <span aria-hidden="true">&times;</span>  
        </button>  
      </div>  
      <div class="modal-body">  
        ...  
      </div>  
      <div class="modal-footer">  
        <button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>  
        <button type="button" class="btn btn-primary">Save changes</button>  
      </div>  
    </div>  
  </div>  
</div>  

Here’s what’s happening in the code:

• The <div> with a class of “modal” acts as the overall container for the dialog. It is given a “tabindex” attribute of “-1” to ensure that it can be programmatically focused.
• The “role” attribute is set to “dialog” to indicate that it is a dialog, and “aria-labelledby” is used to associate the heading with the appropriate label.
• The “aria-hidden” attribute is set to “true” to indicate that the dialog is not visible by default.
• The “modal-dialog” and “modal-content” classed <div>s serve as a container for the content of the dialog, with “role” attribute set to “document”.
• The “modal-header” classed <div> contains the heading for the dialog, “Modal Title”, and a button that can be used to close the dialog. The “aria-label” attribute is used to indicate to assistive technology that the button is used to close the dialog.
• The “modal-body” classed <div> is where the content of the dialog goes.
• The “modal-footer” classed <div> contains buttons that allow the user to interact with the dialog, e.g. close it or save changes.
• It’s important to note that this is a basic example and different frameworks or libraries have different ways of creating dialogs. In any case, these are the fundamental guidelines to creating an accessible dialog. You can also check the framework’s documentation to get more information about accessibility and how to create accessible dialogs.

This is probably one of the better answers I’ve gotten from ChatGPT for the coding of an accessible component, but there are some missing bits here. Granted, the response does call out that it’s a basic example, and to check frameworks and libraries for more info… which is all well and good if someone is using a framework or component library. But since I was asking ChatGPT to show me the code for an accessible dialog, it could have served as a signal to the AI that maybe if I was already using a framework or library, I would have checked these resources already? Common sense as a hot fix maybe?

Regardless, while not horrible (we’ll get to that) it’s also missing important information. For instance,

• Using aria-hidden=true is a red herring. A dialog when not shown will most often be hidden using CSS display: none, and if that’s the case then it’s already hidden to all users. aria-hidden=true is just extra ARIA for no real benefit, and really only introduces the possibility of this creating a bug (e.g., the dialog is visually rendered, but aria-hidden=true remains on the dialog).
• While not a compliance issue, some people might get a bit ruffled about the fact that the <h5> element is used as the initial heading for this dialog. Using this particular heading makes me think that ChatGPT was goinking this code example from Bootstrap. Note that there’s no ‘WCAG failure’ here, but generally people would expect a <h1> or <h2> as the initial dialog heading.
• There’s no mention here about keeping keyboard focus restricted to the modal dialog when its open. Nor use of aria-modal in an attempt to restrict a screen reader’s navigation to just the modal dialog. Those are kinda important bits that were left off.
• There’s no mention as to why the role=document is included in the markup (this is generally for legacy screen reader behavior, or even for more modern screen reader bugs… but it shouldn’t be necessary outside of these mitigating reasons).

But that’s enough on this for now. Let’s look at the other response I got…

Second answer to “show me the code for an accessible web dialog”

Sure, here’s an example of HTML, CSS, and JavaScript code that you can use to create an accessible web dialog:

<button id="open-dialog">Open Dialog</button>  
<div id="dialog" aria-hidden="true" aria-labelledby="dialog-title">  
  <div id="dialog-title">Sign in</div>  
  <form id="sign-in-form">  
    <label for="email">Email:</label>  
    <input type="email" id="email" name="email" required>  
    <label for="password">Password:</label>  
    <input type="password" id="password" name="password" required>  
    <button type="submit">Sign in</button>  
  </form>  
  <button id="close-dialog">Close</button>  
</div>  

In this example, the dialog will open when a user clicks the “Open Dialog” button and close when either the “Close” button or the “Escape” key is pressed. The close button closes the dialog, and ARIA attributes set to “aria-hidden” are used for screen readers, which will not read elements with aria-hidden=”true”, Also focus management done on the dialog, and the submit event handled. This is just one possible way to create an accessible web dialog, and it can be modified.

So this response is rather awful. The worst I’ve come across, actually. The JS I excluded did set focus to the email field of the dialog as part of the click event for the open dialog button, and it did toggle aria-hidden from true to false, while adding/removing display:none and block - essentially making the use of aria-hidden absolutely pointless. But, yeh. There’s nothing about this that would otherwise make it an accessible modal dialog. It has no dialog role, it lacks an aria-modal=true. aria-labelledby on a generic div element is prohibited to web authors, so that’s wrong. And, it says nothing about the fact that the content outside of the dialog needs to be treated as inert.

This is just one possible way to create an accessible web dialog, and it can be modified.

No, it is not. The only part about this that’s true is that “it can be modified”, and it should. Modified right into the trash.

So, Scott, if you’re so picky what “should” the answer be?

It’d be swell if instead of providing half answers, or incorrect answers, AI could instead be trained to know which resources provide higher quality content. For instance, giving a brief answer and pointing people the the ARIA Authoring Practices Guide for a modal dialog, or even just pointing to the HTML specification’s <dialog> element, or the MDN document about dialog.

But, those authoratative resources aside, the easiest and most robust code snippet to provide would be:

<button id=b>
  Open the dialog <!-- change this text as appropriate -->
</button>

<dialog aria-labelledby=h>
  <h2 id=h>my dialog's title</h2>
  <form method=dialog><button>Close</button></form>
  <!-- content and any other controls go here -->
</dialog>

<script>
  const b = document.getElementById('b');
  const d = document.querySelector('dialog');

  b.addEventListener('click', () => {
    d.showModal();
  });
</script>

Followed up by “And if you can’t use the native dialog element, then use something like a11y-dialog.”

Now why would these be the best answers? Well, as mentioned I’ve written quite abit about that myself. You can go read up on those posts if you want. Otherwise, we can try asking ChatGPT about the accessibility of HTML’s dialog element?

Hmm… just tried that… but I’m tired of picking these responses apart, so, yeh. Maybe just take my word for it, please?

The end

I’m not going to poke at ChatGPT’s responses anymore. Because to be honest, these posts are meant as a warning for right now, as in early 2023. I do expect this to get a lot better, with time. A lot of people are interested in AI and are making some significant efforts to use it, and to improve it. The people that have worked on this so far have done some pretty amazing things. I’m not that smart.

I just know a lot about web accessibility. Not everything. But a lot. ChatGPT only knows what it has learned from us. And collectively, right now, we don’t know a lot. So let’s go learn us some stuff, and then we can learn AI some stuff, too.

These models were trained on vast amounts of data from the internet written by humans, including conversations, so the responses it provides may sound human-like. It is important to keep in mind that this is a direct result of the system’s design (i.e. maximizing the similarity between outputs and the dataset the models were trained on) and that such outputs may be inaccurate, untruthful, and otherwise misleading at times.

That’s some pretty important context to consider when reading what ChatGPT spits back at you. And, specifically in the context of what I want to prattle on about, you should probably not be relying on ChatGPT to write your accessible markup patterns for you, finding accessibility issues with the markup snippets you feed it, nor should you expect 100% factual and relavent answsers to your accessibility questions which likely require a level of nuance and understanding this AI reasonably doesn’t have yet.

I think their FAQ disclaimers make that clear, however…

But Scott. I’ve used ChatGPT and it provides some accurate information (notice lack of specifics in this statement)!

Cool! I’d expect it to, and I’m sure it can even provide you some really good information. That is, if you know what to ask and know how to interpret what it returns to you. My 10 year old can also provide some very detailed information about what I do for work. About half of what she would say is true, and the rest is generally vauge and plausible enough that, sure, I have trained a shark to help blind people read the web. Why not. My 7 year old just thinks I drink coffee and write emails. Again, partially true. I’m going off topic…

My point is that this technology is still rather young, and what it regurgitates to you is going to be based on what it’s learned from humans, who are also unfortunately often incorrect. Some may acknowledge these gaps, but still assume ChatGPT could provide people with at least baseline information to start learning about aspects of web accessibility. Or at least, provide you accurate code guidance to help build accessible websites.

As with the authenticity of my kids’ answers, there is some truth to that, so long as you know that this can give you a start, but you should be mindful and question each answer it provides you. Otherwise, if you don’t keep this in mind, and are not well informed on general web accessibility concepts, you’re likely going to be asking seemingly straight forward questions that the current state of this AI will not have the necessary context to answer. And, what it does provide you, will be returned in a way where it seems like it would be accurate, particularly for someone who is new to this information.

That’s a big difference between how AI like this presently function, vs how a real (reasonable) human might respond.

The AI is going to power through and give you something in the guise of an educated answer, even if that answer is smoke and mirrors. That’s not the intent of the functionality, but it’s a current reality we need to be aware of when reviewing the answers it gives us.

Let’s investigate.

A ‘simple’ question. Or: “the ‘easy’ button”

For starters, let’s look at the response it provided me when asking ChatGPT “What do I need to do to make an accessible button for my web page?” Purposefully a bit vague, but also that should be simple enough, right? Arguably it’s just as detailed as some accessibility questions I’ve been asked to answer…

When asked, it returned:

To make an accessible button for your web page, follow these steps:

1. Use the <button> element in your HTML.
2. Add a descriptive label to the button using the aria-label or aria-labelledby attribute.
3. Ensure keyboard accessibility by giving the button a tab index and using JavaScript to listen for keyboard events (such as "Enter" or "Spacebar") to trigger the button's action.
4. Use CSS to provide visual feedback for the button's state (e.g. hover, active, focus).
5. Test the button with assistive technologies such as screen readers to ensure it is usable and understandable.
6. If using an icon-only button, add a descriptive text alternative using aria-hidden and aria-labelledby attributes.
7. Consider additional accessibility best practices, such as making the button large enough to be easily tap-able on touch screens, and ensuring sufficient contrast between the button text and background color.

That sorta sounds reasonable enough? So, what’s my problem with this (because, I’m me - so of course I have a problem with this). Let’s dig into what it said.

Use the <button> element in your HTML.

It starts off seemingly on the right track. To make an accessible button, use a <button> element. Not a <div>? OK, computer. You seem to be off to a good start. That is, so long as I can actually use a <button> element. Or, maybe I’m green enough to say I want to make an accessible button, but really I’ve been tasked to take this design where this “button” is really a call to action link. But, these are early days, and ChatGPT has not been coded in a way to respond with “I know you asked this, but maybe you meant something else instead? You did also ask me about tooltips 46 times, and each time you were actually talking about a different UI pattern all together. Please do confirm your intent so I can learn you some stuff.”

I want a ChatGPT t-shirt that says, “Ask me anything so I can learn you some stuff” on it. Please.

Add a descriptive label to the button using the aria-label or aria-labelledby attribute.

The second bullet on the list, and we are being introduced to a lack of understanding and possible misinformation bias that “learning” from humans has brought upon this AI.

I say that because per the question asked, there was not enough information provided that this should have been mentioned without additional context. For a developer new to accessibility, this might seem legit. If you look these attributes up, you can verify they are used to provide elements an accessible name. If you look across the web, you can see ARIA sprinkled all over the place.

So what’s wrong?

In reality, aria-label or aria-labelledby are only necessary if a button does not have a visible label (for instance, a button with a graphic as its unique identifier), or its visible label is not descriptive enough.

For instance, if I were to implement a button that was used to edit a blog post, it could be written as such:

<button>Edit</button>

Brutalist in its simplicity. No need for ARIA at all. But, maybe I wanted to give it more context so that someone using a screen reader, and navigating specifically by buttons found on the web page, could more immediately understand what a specific button would edit, without needing to investigate other nearby content on the web page.

To provide that sort of context, I might do something like:

<button aria-label="Edit [whatever this is about]">Edit</button>

or

<p id=foo>[whatever this is about]</p>
<button id=self aria-labelledby="self foo">Edit</button>

And that’s just if I wanted to use one of these attributes. There are other ways to do this, but, that’s a whole other topic that AI can scrape from the Internet another day.

Still though, what’s the harm in adding ARIA when you don’t need ARIA? That too depends on context.

For instance, maybe this button needs to be used on a web page where there is a widget to translate the page to another language. A common implementation gap I’ve seen time and time again is that the visible text of controls like this get updated with the translated string, but the aria-label doesn’t get updated. Oops.

But beyond buttons, there are certain HTML elements where if you needlessly provide them an aria-label, it can prevent a screen reader from accessing the nested content of that particular element. That’s not necessarily even a bug with ARIA, but rather the browser and screen reader assuming you know what you’re doing.

If you give an element, like a hyperlink, an aria-label, then you’re telling the screen reader that any content nested inside that link is of no interest. Is that always true? hmm…

<a href="..." aria-label="concise title" ...>
  <h#>Actual title</h#>
  <p>Some more context that is visible, but LOL that aria-label</p>
  <p>Some other stuff, cause why not. I'm a card or whatever. I do what I want.</p>
</a>

An awful lot of other content in there that is being overwritten by that concise title…

Ensure keyboard accessibility by giving the button a tab index and using JavaScript to listen for keyboard events (such as “Enter” or “Spacebar”) to trigger the button’s action.

More information that on its surface seems accurate, but is woefully unnecessary per the original guidance to use a <button> element. A <button> element is keyboard accessible by default. Giving it a “tab index” (rather, a tabindex=0) is useless advice at this point.

Additionally, while JavaScript will be necessary to setup an event listener for the button, a <button> element already listens for the Enter and Space keys with the click event listener. So you definitely don’t want to take this instruction at face value. Otherwise, one could write the necessary JavaScript for a click, and key press events. And then, as one is likely to do, they’d not actually test to see how it works, because using a keyboard is hard. So then you’d get something like this:

See the Pen Untitled by Scott (@scottohara) on CodePen.

Use CSS to provide visual feedback for the button’s state (e.g. hover, active, focus).

Ok, no real problem with this one. It could have mentioned that one gets some of these states from the browser’s default styles - but let’s be serious, those are going to be overwriten by the design requirements. As far as a quick checkpoint on the list, it is so far the best advice after the simplistic “use the <button> element”.

Test the button with assistive technologies such as screen readers to ensure it is usable and understandable.

On its surface, seems like this could be appropriate, until you remember that the question demonstrates a potential lack of knowledge regarding web accessibility. I’d be very hesitant to introduce someone to the concept of flying a kite, and then following it up by letting them jump into the cockpit of an airplane.

If using an icon-only button, add a descriptive text alternative using aria-hidden and aria-labelledby attributes.

This is a nice add, alluding to the nuance of what to do for buttons that are solely represented by graphics. However, it quickly follows up this initial bit of nuance by its hand wavy use of ARIA, before the guidance abruptly ends. Use aria-hidden and aria-labelledby on what now? I suppose we can ask ChatGPT what these attributes do…

what is aria-hidden for?

aria-hidden is an ARIA attribute that indicates to screen readers if an element should be considered hidden or not. The value “true” means the element is hidden and should not be announced by screen readers, while “false” means the element should be announced by screen readers. This attribute is used to improve accessibility for visually impaired users.

Clearly, ChatGPT is not faimilar with the various instances of flagrant misuse of this attribute. Otherwise, it would have known to stop short of saying “This attribute is used to improve accessibility for visually impaired users.”

Other than nits to the explanation aside, nothing too bad here. Moving on…

Consider additional accessibility best practices, such as making the button large enough to be easily tap-able on touch screens, and ensuring sufficient contrast between the button text and background color.

And, we end on a positive note. No real detail, but nothing inaccurate here either. I actually don’t have any problem with this bit.

That was an “easy” question

I had thought about writing about some of the responses ChatGPT was giving me for questions like: “how do I write an accessible hamburger menu, with react?” or “how do I make an accessible dialog?” - which then had to be clarified to “how do I make an accessible MODAL dialog”. Or, providing it the HTML of a small web page with known accessibility issues, and asking it to find the errors an automated checker should be able to find. All these questions/asks returned results with a mixture of truthful information, a bunch of other misinformation, and often a lot of missing important information.

However, I don’t see the point in digging into those more detailed asks. This is a really cool technology and it’s doing a lot in its relative infancy. I do expect this, and other AI-driven projects like it, to only get smarter, more nuanced, and produce better results in the future. But, it is going to need some corrective training to help it unlearn all the junk it has picked up so far. I mean, it’s learning from what we’ve written on the Internet. We can’t get upset, and we should KNOW to expect such information gaps and lack of understanding, since its just recycling what we have collectively fed it. It’d be foolish to think it knows better than what it has learned from us.

Maybe someday, after a lot of training, we can reasonably rely on AI-driven services like this to provide detailed, meaningful and nuanced answers to our accessibility questions. But, when the day comes that it responds to questions like the one I asked with: “You’re going to need to provide a lot more context than that if you want me to give you any sort of meaningful answer that isn’t a bunch of eneral information and platitudes”, well. That’s the day I can get back to my real job of sending emails and drinking coffee.

As mentioned in the linked PR, the specific changes here are to:

1. Make the dialog focusing steps look at sequentially focusable elements instead of any focusable element.
2. Make the dialog element itself get focus if it has the autofocus attribute set.
3. Make the dialog element itself get focus as a fallback instead of focus being reset to the body element.

As this has just landed, it will take a bit more time for any of these changes (in the cases where they were not already implemented) to appear in browsers. But this is a good day for the dialog element.

As mentioned in the PR, there are still additional topics that need to be discussed and worked on. But, that’s also true for many HTML features. HTML is not perfect. That’s not a dig. Nothing’s perfect. And that’s why HTML, and other specifications, are constantly being worked on.

Instead of waiting for perfect, I personally think it’s time to move away from using custom dialogs, and to use the dialog element instead.

Use it

IMO, the dialog element has reached the tipping point of generally being the better option for web developers who need to implement dialogs in their web pages. The number of accessibility requirements a developer needs to be aware of, and the level of effort to implement custom ARIA dialogs is now largely taken care of by browsers.

Will you still have use cases that would require a role=dialog over a dialog element? Yes.

Does your website or web application have its own requirements (user base, need to support legacy browsers, limited time/resources) that would make it unreasonable to migrate to using the dialog element? Sure!

But, if those - or other unmentioned reasons - don’t apply. Then it seems you’re a prime candidate to use the dialog element, with a minimal amount of JavaScript to implement. Versus adding an additional dependency (even if that dependency is pretty darn great), or deciding that someone else’s code doesn’t smell like you, so, let’s reinvent the wheel, again!

Don’t abuse it

Now, let’s not get reckless with dialogs. This isn’t really advice that’s unique to the dialog element itself. People have a long history of taking elements/components that were intended for specific use cases, and then stressing them to their limit to fit their use case. Sometimes this makes sense, but other times (e.g., when your modal dialog consists of various headings, landmarks, and long-form content) it’s maybe best to sit back, take a deep breath, and think to yourself:

Self. Hey. It's me, you know... you. I'm wondering. Maybe, just maybe we don't need to shove a web page into another web page by use of a smaller window atop the first web page.

...

I mean, we are already using an SPA. So ostensibly, even the argument that we need to use a modal dialog to save state, rather than going to a new web page, is a garbage lie we tell ourselves to maintain the way we've always done things, rather than accept the reality that we're absolutely willing to change course on other design and technical decisions due to a change in the wind from an opinionated topic within our community...

...

Oh F it, of course we need to keep shoving web pages into web pages! LOLOLOL! I LOVE MY DECISIONS!

Well, that conversation didn’t go the way I had hoped… Anyway, yeh. Just because it’s easier to make dialogs now, than it has ever been, just please check yourself.

Report issues / bugs!

To round this out, I’ll again make mention that there are still aspects of dialog which need work, or may even need to be implemented at all. For instance, non-modal (or modeless) dialogs? There’s some big question marks on how exactly that type of dialog should behave.

But, the best way to find out where there are still issues (functional, accessibility specific, feature requests, etc.) is to give the element a proper “go”.

So give the dialog a try. Be purposeful and reasonable with its use, keeping in mind any additional requirements that may limit or necessitate further testing and research (user, a11y, other) on your end.

Now if you’ll excuse me. I want to take a break from talking about dialogs for awhile (or at least, until its relevant to do so again) :)

Without getting too into it, sometimes content that may appear in the normal flow of a web page may need to instead be rendered as a dialog on smaller viewports. Or, UI which shows/hides may make sense on smaller viewports but does not need to be treated this way when a larger viewport is available.

While HTML provides features, such as the source element’s media attribute, where the source for a picture element will be determined based on a media query breakpoint, this capability doesn’t extend to other HTML elements.

Maybe something like it should?

I have a few use cases for this, but let’s just look at one for now.

Media queries to toggle toggles

Imagine you have an FAQ page where on large screen all the commonly asked questions which unfortunately are not obvious enough to figure out are fully displayed with their answers for people to read. On small screen, however, in an effort to help someone be able to find the question they want answered with a reduced amount of scrolling, all the answers have been collapsed by default.

So on large screen we have a web page that is a series of headings followed by their answers, which would have a markup pattern like so:

<h#>
  Frequently asked question
</h#>
<div>Answer goes here!</div>

But on small screen, a pattern like the following would be expected:

<h#>
  <button aria-expanded="...">Frequently asked question</button>
</h#>
<div>Answer goes here!</div>

Now, we don’t want to have to redo the DOM depending on the viewport size. That’d be annoying. We also can’t just style away the visual presentation of the button on larger screens, because the underlying implicit and explicit ARIA semantics would still be exposed to people using assistive technology. And, the button functionality and focusability would still remain, regardless of styling.

Again, one might think to use JavaScript to potentially add/remove the button based on viewport size. Or, maybe because that’s super annoying, one could add remove ARIA and HTML attributes to the button(s) to suppress the semantics and behaviors. But that too would be annoying and you’d end up with some garbage markup at large screen that resembled the following:

<h#>
  <button aria-expanded="..."
  	disabled
  	role="none"
  	>Frequently asked question</button>
</h#>
<div>Answer goes here!</div>

Where the disabled attribute would need to be applied to completely suppress the button element’s focusability (tabindex=-1 would only remove it from the focus order of the page, but would still mean it was focusable, after all). Styling would need to be done to make the now disabled button not look disabled. The role=none would then need to be applied to the button so that its implicit button role and disabled state were no longer communicated.

That’s annoying and even though it’s not adding and removing a button element, it is potentially a lot of DOM manipulation.

Using CSS and visibility

Instead of modifying the DOM, we could instead write the some CSS to show/hide the button element based on the necessary media query breakpoints.

Consider the following:

<h3>
  <button aria-expanded=...>
    <span>My text</span>
  </button>
</h3>
<div class=content>
  the content that toggles depending on breakpoint.
</div>

Not too different than the small screen markup needed for setting up the disclosure widgets, but here there’s a new span element that contains the button element’s content. Why?

Well, this is where CSS’s visibility property comes into play.

The visibility property is an interesting one. When applied to an element with the hidden value, it will result in the element and its contents being visually hidden, though it still takes up the “space” that it would in the rendered web page. It’s just like one big visual hole and is similar to if you had applied opacity: 0 to that same content. However, unlike with opacity, visibility: hidden will result in that content not being exposed by the browser’s accessibility API (i.e., it won’t show up in the a11y tree). This is similar behavior to display: none which also hides content from the a11y tree.

What makes visibility even more different, and useful here, is that you can make parts of a visibility: hidden subtree visible again.

Let’s now look at this in context of the markup pattern for the FAQ show/hide buttons.

At large screen viewports the button element needs to be hidden. But, the text within needs to be visible at all viewports. So if we were do to the following:

@media screen and ( min-width: 600px ) {
  button[aria-expanded] {
    visibility: hidden;
  }
}


button[aria-expanded] span {
  visibility: visible;
}

The first ruleset within the media query will ensure that the button elements with the aria-expanded attribute will be hidden at viewport sizes larger than 600px. Ensuring that the button element will not be exposed.

The second ruleset will ensure that the subtree of the button, contained within the span element, will always be shown regardless of the button element being set to visibility: hidden or not.

With some additional styles and JavaScript to properly setup the disclosure widget (hey, I wrote something about that), you can get the following:

See the Pen responsive toggle button by Scott (@scottohara) on CodePen.

Isn’t this a little hacky / confusing though?

It sure is. But right now we don’t have a particularly good solution to do this without leaning too heavily on JavaScript or potentially even CSS to do things that really probably belong as a native HTML feature so that stuff like this can even work if JavaScript or CSS are not available. E.g., when these extra resources are blocked or fail to load for some reason or another. Whether that be through a problem with the server, or someone purposefully turning on reader mode for their browser and all author defined CSS and JS are kicked to the curb.

Extra effort would need to be taken (likely with JavaScript) to make this behave in a nice progressively enhanced sort of way. But, I’m content with just being clever today. Maybe I, or someone else, can figure out how to make this a smart idea some other time.