An irresistible HTML element deep dive from Ire Aderinokun, this time on the
<abbr title=""> element for abbreviations. You can kinda just use it (JUI) and it works fine, but if you’re hoping to make a tooltip for them (which works on touchscreens as well), then it’s much more complicated.
I feel like this is the perfect sort of thing to be made into a web component that could/should be widely distributed for use. Maybe a
<a11y-abbr> component or something. Can you have web components extend other native HTML elements though? If not, I guess it’s kinda falling back to what is essentially a
<span>, so maybe that’s not ideal.
Dare I say it, this is also the kind of thing where React can excel. For example, I use Reach Router, and by default, when creating links (
<Link>s that turn into
<a>s), they get the proper
aria-current attribute when it’s the current page. That’s good accessibility you’re getting for free because the library was good enough to get that detail right. As much as libraries like React get pointed at for problematic accessibility, there is a lot of potential for accessibility improvements through abstraction. Sort of like the way Brad Frost has been enforcing accessibility best practices in React components.
Mostly what I use it for is to contain a Table of Contents for the page. I put the Table of Contents in multi-level unordered list. Before the details I have a link that says “skip past table of contents” which links to the first section ID after it, that is because some screen readers will read the contents of a details node regardless of whether it is open or not, so it the details has a lot in it, it is handy to give a way for screen readers to skip past it.
I use to use a polyfil but that would sometimes break in a browser update – so now I do not bother, if the browser does not support details it is just always open.
I found it useful to give the summary element a yellow background and when the details is closed by default, I put in parenthesis (click me to expand) – amazing how many people do not know to do that unless that is in the summary.
As far as a tool tip, honestly I think details is the wrong tool for the job, that I think needs to be handled in a div with pure JS and CSS.
It would be nice if there was an actual tooltip elements.
I wonder if this is a case where the cusor-based handling of the title attribute is so ubiquitous that a consensus should be reached on handling tooltip-like behavior on touch devices as well and implemented by mobile browsers. Then again, mobile browsers have been around for so long now that such a drastic change could be problematic and break existing sites.
Tough call, that. It just feels like a shame that a ~50 line polyfill is necessary to handle tooltips on mobile.
It also brings to mind a thought I had about blogged about wherein we allow browsers to take a more prominent role in default styling/handling of content to facilitate faster loading and better experiences. If that ~50 line polyfill or a similar experience were used across a large swath of the web, maybe it’s a thing that needs to be supported at a lower level.