TL;DR: I’ve forked the splendid but dated Tota11y accessibility visualisation toolkit, added some extra stuff and corrected a bug, and my employer has let me release it for Global Accessibility Awareness Day.
A while ago, my very nice client (and now employer), Babylon Health, asked me to help them with their accessibility testing. One plan of attack is an automated scan integrated with the CI system to catch errors during development (more about this when it’s finished). But for small content changes made by marketing folks, this isn’t appropriate.
We tried lots of things like Wave, which are great but rather overwhelming for non-technical people because they tend to cover the page being analysed with arcane symbols, many of which are beyond a CMS content editor’s control anyway. There are lots of excellent accessibility checks in Microsoft Edge devtools, but to a non-technical user, this is how devtools look:
Then I remembered something I’d used a while ago to demo heading structures, a tool called Tota11y from Khan Academy, which is MIT licensed. Note, this is not designed to check everything. Tota11y is a simple tool to visualise the most widespread web accessibility errors in a non overwhelmingly-techy way. It aims to give content authors and editors insights into things they can control. It’s not a cure-all.
There were a few things I wanted to change, specifically for Babylon’s web sites. I wanted the contrast analyser to ignore content that was visually hidden using the common clip pattern and to correct a bug whereby it didn’t calculate contrast properly on large text, and reported an error where there isn’t one. False positives encourage people to ignore the output and this erodes trust in tools. The fix uses code from Firefox devtools; thank you to the Mozilla people who helped me find it. There’s loads of other small changes.
Khan Academy seemed to have abandoned the tool, so I forked it. Here it is, if you want to try it for Global Accessibility Awareness Day. Drag the attractive link to your bookmarks bar, then activate it and inspect your page. The code is on GitHubdon’t laugh at my crap JavaScript. It was also an “interesting” experience learning about npm, LESS, handlebars and all the stuff I’d managed to avoid so far.
Feel free to use it if it helps you. Pull requests will be gratefully received (as long as they don’t unnecessarily rewrite it in React and Tailwind), and I’ll be making a few enhancements too. Thanks to Khan Academy for releasing the initial project, to my colleagues for testing it, to Jack Roles for making it look pretty, and to Babylon for letting me release the work they were nice enough to pay me for.
Update: Version 1.1 released
17 June 2021: I’ve made some tweaks to the Tota11y UI. A new naming convention replaces “adjective+animal I’ve never eaten”. V 1+ are “adjective+musical instrument I’ve never tried to play”. V1.1 is “Rusty Trombone”.
Yesterday I asked “What’s the most up-to-date info on aria-live regions (and
Heydon replied
Should be fine, support is good for live regions. Not sure about output, though … Oh, you’re adding the p _with_ the other XHR content? That will have mixed results in my experience.
Brennan said
I’ve seen some failed announcements with live-regions on VoiceOver, especially with iframes. (Announcement of the title seems to kill any pending live content).output has surprisingly good support but (IIRC) is not live by default on at least one browser (IE, I think).
I’ve been working on a client project and one of the tasks was remediating some data tables. As I began researching the subject, it became obvious that most of the practical, tested advice comes from my old mates Steve Faulkner and Adrian Roselli.
I’ve collated them here so they’re in one place when I need to do this again, and in case you’re doing similar. But all the glory belongs with them. Buy them a beer when you next see them.
Gosh, what a snappy title. I’m not expecting a job offer from Buzzfeed any time soon.
Today, Apple sent their consolidated feedback on Web Components to the webapps Working Group. The TL;DR: they like the concept, are “considering significant implementation effort”, but want lots of changes first including removal of subclassing, eg <button is=”my-button”>.
I think this is bad; this construct means existing HTML elements can be progressively enhanced – in the example above, browsers that don’t support components or don’t support JavaScript get a functional HTML <button> element. It also means that, by enhancing existing HTML elements, your components get the default browser behaviour for free – so, in this example, your snazzy my-button element inherits focussability and activation with return or spacebar withut you having to muck about with tabindex or keyboard listeners. (I wrote about this in more detail last year in On the accessibility of web components. Again.)
Apple raised a bug Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement and notes “without this hack accessibility for trivial components is harder as more things have to be done by hand” (why “this hack”? A loaded term). However, it calls for removal because “Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based.”
Implementation is hard. Too hard for the developers at Apple, it appears. So Web developers must faff around adding ARIA and tabindex and keyboard listeners (so most won’t) and the inevitable consequence of making accessibility hard is that assistive technology users will suffer.
HTML has a series of design principles, co-edited by Maciej Stachowiak who sent Apple’s feedback. One of those is called “Priority of Constituencies” which says
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.
A while ago, there was discussion in CSS Working Group about an alt property to be added to CSS. Its purpose is to let assistive technology know the meaning of unicode characters inserted into a visual rendering of a document with CSS generated content. The problem is described by James Craig, Apple’s nice accessibility chappie.
It’s been shipping as -webkit-alt for a year now, and has just been added to the draft CSS Pseudo-Elements Module Level 4 spec. Let’s say you’re using a star glyph to show something is “new”, by generating CSS content using a class of .new as your selector:
The alt gives information to assistive technology.
The alt string can be blank. Assume you’re generating “►” to show that a widget is expandable. Because you’re a lovely human being and a responsible developer, you’re using aria-expanded="false" in the HTML. Therefore, you’d use empty alt in the CSS that generates the glyph to prevent assistive technology “helpfully” reading out “Black right-pointing pointer” after the AT has relayed the ARIA information to the user:
.expandable::before {
content: "\25BA"; /* a.k.a. ► */
alt: "";
/* aria-expanded="false" already in DOM,
so this pseudo-element is decorative */
}
Update 17:05 GMT fantasai of the CSS WG has mailed the CSS Working Group protesting against the syntax above. I don’t have any horse in the syntax race; my aim with this post is to show that we need some mechanism to give alternate content to assistive technology given that we allow non-textual content to be generated via CSS.
When I tweeted about this earlier, a few people objected to the concept because it adds content to CSS. But that ship has long sailed, with the content property that people have been using for ages. If you say “adding non-decorative content to a page is a misuse of CSS that merits the author 100,000 years in purgatory with Tim Berners-Mephistopholee pouring hot Ovaltine over their dingle-dangles whenever they try to sleep”, I will vehemently nod my agreement.
But sometimes, for organisational reasons, or because you inherited code, or you’re refactoring code from before you saw the light, you’re working with CSS that generates icons. This new property at least allows an author to make that content more accessible.
Years ago, I joined a web team a week after their brand new website had been delivered, months late and squillions over budget, by Big London Agency PLC. The site was a vile splodge of nested layout table cells and spacer GIFs with “click here” links pointing to PDFs. Of course, I could have instantly resigned my job and let the bank repossess my house.
Instead, I gently pointed out to any who would listen the inadequacies of the site and made plans about how it could be refactored. But while biding my time, I was also making small tweaks here and there to make it better and incrementally more accessible; removing duplicate link text from title attributes, changing “click here”s, putting blank alt text on spacer GIFs in the small parts of the template I controlled.
This was before the days of ARIA but I would have jumped at the chance of adding role="button" to the horrible mess of nested <div>s that the CMS spat out. Yes, it’s much better to spend a fortune getting the external CMS provider in to change the templates, the retest every single form on every single browser – but that simply wasn’t possible.
Two years later, when the senior manager who commissioned the terrible site left and we could jettison it, we did. And then we did it right. But for those who needed the content and were unable to wait nearly three years (that is, everyone), I’m glad I applied sticking plasters and polished turds.
It’s often said that if a job’s worth doing, it’s worth doing well. But it’s also wise to remember: sometimes, if a job’s worth doing, it’s worth doing badly than not at all. If you must have meaningful content generated by CSS, at least now you can make it accessible.
It announced “Warning Be careful in VO/Chrome combo. All other browsers I tried on Mac ignored the whole line, so no pseudo content added. Andy Ronksley wrote
The alt text is added to the content property now (after the forward slash). Last time I used this a few years back, Safari only supported the older syntax. Sounds like Ian has confirmed it still doesn’t support the new syntax.
A chum asked me “why use role=contentinfo instead of role=footer for <footer>?”
role attributes are from the Accessible Rich Internet Applications (WAI-ARIA) spec, and not part of HTML(5), although they’re allowed in pages. They’re developed by different groups, and for different reasons. ARIA is a bridging technlogy for any markup language – HTML4, SVG or HTML5 to “plugin” accessibility information that isn’t part of the host language:
WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page…
It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.
contentinfo is defined as an ARIA landmark on a page. It’s primarily there so assistive technology can allow a user to navigate around. The ARIA spec describes contentinfo as
A large perceivable region that contains information about the parent document. Examples of information included in this region of the page are copyrights and links to privacy statements. Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.
This is a good description of a page footer, but HTML5 allows as many <footer> elements as you want:
The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
The HTML5 <footer> does give “content info” but does so about its parent, which may be one of many <article>s or <section>s. Another element that gives information about the content it’s in is the <address> element, which may (but doesn’t have to) take an ARIA role of contentinfo.
So there’s not a 1-to-1 correspondence between <footer> and role="contentinfo". This is exactly the same as the correspondence as we see between <header> and role="banner". So it’s probably less confusing that the HTML5 element and the ARIA roles have different names.
It seems that the name <footer> was adopted as it was the most common class name found in a billion web pages analysed in 2005 by Ian Hickson, HTML5 editor. Arguably, contentinfo is a better “semantic” name (after all, information about content doesn’t have to be below the content it refers to, which is what “footer” implies), but “footer” is what people were already using. Anyway, the naming of the new HTML5 elements is done now. There’s no use in bikeshedding once the ship has sailed, as Captain MixedMetaphor says.
The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it. Good; that’s the way it should be.
However, until all do, you give a helping hand by explicitly adding that role on the page-wide footer.
I’ve just changed my site to use the new <main> element. It took about 1 minute to work out what was wrong with my CSS, until I realised that I hadn’t defined main {display:block;} (the CSS spec says that all elements are inline by default, unless over-ridden). I expect that the HTML5 shiv will add this in, but I don’t use the shiv (it was written after I converted the site). If you use the html5shiv on GitHub, the latest version includes support for <main>.
If you use something like <div id=”main”> (or similar, such as <div id=”content”> as I was), simply replace that with <main role=”main”>.
The <main> element is an exact analogue of ARIA’s role="main", and is designed to show screenreaders and assistive technologies exactly where main content begins, so it can be a target for a “skip links” keyboard command, for example. It could also be used for content syndication (Instapaper-ish things); mobile browsers could zoom in on <main> when encountering non-responsive websites.
It should therefore be used once per page. Therefore, the WHATWG spec is wrong when it says “The main element can be used as a container for the dominant contents of another element.” as this suggests that it may be used multiple times. Don’t. Otherwise, the benefits will be lost.
The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application…
Authors must not include more than one main element in a document.
Authors must not include the main element as a child of an article, aside, footer, header or nav element.
The new element is already in Firefox and Chrome nightlies. The beauty of <main> is that it is already supported in modern assistive tech. Most of these understand aria role=main, as browsers map this to an operating system thingummy (technical term). The thingummy is what the assistive technologies interface with. So in FF nightly and webkit, the new <main> element is mapped to the same thingummy – therefore screenreaders and the like can use it straight away.
Nevertheless, I’m still using ARIA role="main" on the new element as belt-and-braces because you’re almost certainly not using Firefox or Chrome nightlies, and there’s no support yet in Opera or Internet Explorer.
Although I was initially opposed to the new element, I’m firmly in favour of using it, once per page, to give extra built-in accessibility to those who need extra help accessing the Web.
And hearty congratulations to Steve Faulkner, The Paciello Group‘s Kylie Minogue of web accessiblity, for his research and perseverance in getting this in the spec and in some browsers.
For the last four years, those excellent people at WebAIM have surveyed screenreader users about the kit and setup they use. For some reason, I didn’t see this when it came out in May.
Here’s a brief summary of the results to help web developers who care about accessibility (that is, professional-standard web developers). I urge you to read the full report when you have 30 minutes to spare.
The vast majority of screenreader users are on Windows (87%). The runners up are Mac (8.5%) and iOS (3.4%).
The free, open-source screenreader NVDA “saw continued increase in usage, up to 13.7% from 2.9% in 2009 and 8.6% in 2010 (a nearly 500% increase in just 2.5 years)”. You can use NVDA to test your sites and maybe send them a donation; it literally is two blind guys in Australia who maintain it.
The vast majority of respondents (83%) updated their primary screen reader within the previous year. Users of free screenreaders were unsurprisingly more likely to upgrade than paid screenreader users.
Mobile screen reader usage increased 600% in just over 3 years (only 12% reported using a mobile screen reader in January 2009). 58% were on iOS devices, 20% on Nokia, 7.9% on Android.
98.6% of users had JavaScript enabled.
Internet Explorer accounts for 67.5% of the browser share among respondents – IE8 was 34%, IE9+ was 29.5%. Firefox was the runner-up at 20%. “No-one uses IE” is the same as saying “We don’t care about disabled customers”.
ARIA landmarks (banner, contentinfo, main, navigation etc) were used “whenever they are present” by 24.6%, “often” by 15.8%, “never” by 15.6%. This is one reason for my changing my mind to support a proposed <main> element in HTML5.
60.8% said navigating through page headings was their primary method find information on a lengthy web page. Heading structures are therefore very important. See this blind developer’s short video Importance of HTML Headings for Accessibility for more.
The most problematic areas for screenreader users (most frustrating first) are:
The presence of inaccessible Flash content
CAPTCHA – images presenting text used to verify that you are a human user
Ambiguous links. Lose those “read more” and “click here” links, people! This isn’t a new revelation!
Images with missing or improper descriptions (alt text)
Screens or parts of screens that change unexpectedly. (Perhaps judicious use of ARIA Live Regions could alleviate this?)
I want to re-iterate my thanks to Jared Smith and the WebAIM people for collecting, collating and publishing this information.
For a while, people have suggested that HTML add a <content> element that wraps main content, because many websites have something like <div id="content"> surrounding the area that authors identify as their main content, which they then use to position and style that central content area.
Fans of WAI-ARIA also like to hang role="main" on that area, to tell assistive technology where the main content of the page starts. I do this too.
What would the element _mean_? If it’s just “the main content”, then that is what the element’s contents would mean even without the element, so really it means the element is meaningless. And in that case, <div> is perfect, since that’s what it is: a grouping element with no meaning.
The primary argument against a special element is that it isn’t necessary, because the beginning of “main content” can be identified by a process of elimination that I call the “Scooby Doo algorithm”: you always know that the person behind the ghost mask will be the sinister janitor of the disused theme park, simply because he’s the only person in the episode who isn’t Fred, Daphne, Velma, Shaggy, or Scooby. (Like most Scooby fans, I’m pretending Scrappy never existed.)
Similarly,the first piece of content that’s not in a <header>, <nav>, <aside>, or <footer> is the beginning of the main content, regardless of whether it’s contained in an <article>, or <div>, or whether it is a direct child of the <body> element.
Authors do need to be able to identify their main content, both for styling (in which case <div> seems to be the most appropriate element) and as a target for “skip links”, in which case, the current <a href=”#main”>Skip nav<a> … <div id=”main”> pattern still does the trick.
It’s worth noting that people often code “skip links” believing it’s required by WCAG 2, but if browsers implemented the Scooby Doo algorithm that is explicitly not the case: “It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent.”
Many assistive technology useragents understand the ARIA role=”main”, so skip links should be unnecessary; ATs can hone in on <div id=”main” role=main> by themselves, even without supporting the Scooby Doo algorithm.
This suggests to me that a new element isn’t required. But…
To turn the question around, if it is more convenient for authors to identify the main content, and not think about the classification of other parts, should we offer that facility as part of the platform? Or does it make sense to say that only the exhaustive identification of all supplementary content is an appropriate way to mark up a page anyway?
Chaals argues that it makes authoring easier – suddenly you get extra accessibility by just adding one <content> element, rather than adding the other elements that the Scooby Doo algorithm can then exclude. People using CMSs, who only control the textarea that gets lumped in as “main content” and can’t touch the surrounding areas can now add an element, without having to ask others to tweak templates.
But then, they can do this already, by surrounding their content with <div role=”main”> and this already works in assistive technologies.
A flawed argument for a new element is that it paves a cowpath, so should be added to the language. It’s certainly the case that <div id=”main”> and <div id=”content”> are very frequently found in pages – they were #2 and #6 in the most-frequently used ID attributes in the 2008 MAMA: What is the Web made of? report.
But not every cowpath needs paving. If it did, we’d also have a <logo> and a <container> element (#4 and #5 respectively), and we’d be recommending tables for layout. If something can be done automatically, without requiring extra authorial work, shouldn’t that be favoured? In the same way that we like HTML5 form types as they’re baked into the browser, shouldn’t the Scooby Doo algorithm be preferable?
Of course, the Scooby Doo algorithm requires the author to use <header>, <footer> <nav> and <aside> — but if (s)he doesn’t want/ isn’t able to author HTML5, ARIA’s role="main" is there precisely as bridging technology.
There’s also the argument that authors expect there to be a <content> element, so its absence violates the Principle of Least Surprise. But I’m not sure that’s a valid argument. Implementing the Scooby Doo algorithm would mean that pages whose author does nothing for accessibility can be made so that their main content area may be programmatically determined. ARIA exists for pages that aren’t in HTML5, or until the Scooby Doo algorithm is widely supported, and analysis shows that most ARIA is correctly used by authors.
Why add an extra complexity, which is more to go wrong and thus potentially harms accessibility?
A couple of people have asked me recently if it’s possible to nest ARIA roles. The answer: yes.
Not all of them, of course. Think of HTML elements; you can nest <div>s inside <nav>s and <nav>s within <header>s, but you can’t put an <a> inside an <input> or put an <input> inside another <input> – they just wouldn’t make sense.
In ARIA, it’s perfectly fine to have role=article inside role=main (which is completely analogous to an HTML5 <article> inside a <div id=”main”>.
It’s also fine (as far as I know) to have roles like main inside a <table role=”presentation”>. Although the table is presentational only (it’s an old-fashioned layout table), it doesn’t mean that all the contents are presentational – one cell could contain the entire main content of a site and therefore quite legitimately have a role="main".
The rule of thumb I use is: if your nesting feels right, it probably is right.
Note also that the HTML5 validator also validates ARIA. Even if your content isn’t HTML5, it’s still worth running it through the validator.
Note, I’m not an ARIA expert. Please, if I’ve made a mistake, let me know!
