We often have brown bag lunchtime presentations at Clearleft. In the Before Times, this would involve a trip to Pret or Itsu to get a lunch order in, which we would then proceed to eat in front of whoever was giving the presentation. Often itās someone from Clearleft demoing something or playing back a project, but whenever possible weād rope in other people to swing by and share what theyāre up to.
Weāve continued this tradition since making the switch to working remotely. Now the brown bag presentations happen over Zoom. This has two advantages. Firstly, if you donāt want the presenter watching you eat your lunch, you can switch your camera off. Secondly, because the presenter doesnāt have to be in Brighton, thereās no geographical limit on who could present.
Our most recent brown bag was truly excellent. I asked LĆ©onie if sheād be up for it, and she very kindly agreed. As well as giving us a whirlwind tour of how assistive technology works on the web, she then invited us to observe her interacting with websites using a screen reader.
Iāve seen LĆ©onie do this before and itās always struck me as a very open and vulnerable thing to do. Think about it: the audience has more information than the presenter. We can see the website at the same time as weāre listening to LĆ©onie and her screen reader.
We got to nominate which websites to visit. One of themāa clientās current site that we havenāt yet redesignedāwas a textbook example of how important form controls are. There was a form where almost everything was hunky-dory: form fields, labels, it was all fine. But one of the inputs was a combo box. Instead of using a native select
with a datalist
, this was made with JavaScript. Because it was lacking the requisite ARIA additions to make it accessible, it was pretty much unusable to LƩonie.
And thatās why you use the right HTML element wherever possible, kids!
The other site LĆ©onie visited was Clearleftās own. That was all fine. LĆ©onie demonstrated how sheād form a mental model of a page by getting the screen reader to read out the headings. Interestingly, the nesting of headings on the Clearleft site is technically wrongāthereās a jump from an h1
to an h3
āprobably a result of the component-driven architecture where you donāt quite know where in the page a heading will appear. But this didnāt seem to be an issue. The fact that headings are being used at all was the more important fact. As LĆ©onie said, thereās a lot of incorrect HTML out there so itās no wonder that screen readers arenāt necessarily sticklers for nesting.
Iāve said it before and Iāll say it again: if youāre using headings, labelling form fields, and providing alternative text for images, youāre already doing a better job than most websites.
Headings werenāt the only way that LĆ©onie got a feel for the page architecture. Landmark rolesālike header
and nav
āreally helped too. Inside the nav
element, she also heard how many items there were. Thatās because the navigation was marked up as a list: āList: six items.ā
And that reminded me of the Webkit issue. On Webkit browsers like Safari, the list on the Clearleft site would not be announced as a list. Thatās because the listsās bullets have been removed using CSS.
Now this isnāt the only time that screen readers pay attention to styling. If you use display: none
to hide an element from sight, it will also be unavailable to screen reader users. Makes sense. But removing the semantic meaning of lists based on CSS? That seems a bit much.
There are good reasons for it though. Hereās a thread from James Craig on where this decision came from (James, by the way, is an absolute unsung hero of accessibility). It turns out that developers went overboard with lists a while back and thatās why we canāt have nice things. In over-compensating from divitis, developers ended up creating listitis, marking up anything vaguely list-like as an unordered list with styling adjusted. That was very annoying for screen reader users trying to figure out what was actually a list.
And James also asks:
If a sighted user doesnāt need to know itās a list, why would a screen reader user need to know or want to know? Stated another way, if the visible list markers (bullets, image markers, etc.) are deemed by the designers to be visually burdensome or redundant for sighted users, why burden screen reader users with those semantics?
Thatās a fair point, but the thing is ā¦bullets maketh not the list. There are many ways of styling something that is genuinely a list that doesnāt involve bullets or image markers. White space, borders, keylinesāthese can all indicate visually that something is a list of items.
If you look at, say, the tunes page on The Session, you can see that there are numerous listsānewest tunes, latest comments, etc. In this case, as a sighted visitor, you would be at an advantage over a screen reader user in that you can, at a glance, see that thereās a list of five items here, a list of ten items there.
So Iām not disagreeing with the thinking behind the Webkit decision, but I do think the heuristics probably arenāt going to be quite good enough to make the call on whether something is truly a list or not.
Still, while I used to be kind of upset about the Webkit behaviour, Iāve become more equanimous about it over time. There are two reasons for this.
Firstly, thereās something that Eric said:
We have come so far to agree that websites donāt need to look the same in every browser mostly due to bugs in their rendering engines or preferences of the user.
I think the same is true for screen readers and other assistive technology: Websites donāt need to sound the same in every screen reader.
Thatās a really good point. If we agree that āpixel perfectionā isnāt attainableāor desirableāin a fluid, user-centred medium like the web, why demand the aural equivalent?
The second reason why Iām not storming the barricades about this is something that James said:
Of course, heuristics are imperfect, so authors have the ability to explicitly override the heuristically determined role by adding
role="listā
.
That means more work for me as a developer, and thatās ā¦absolutely fine. If I can take something that might be a problem for a user, and turn into something thatās a problem for me, Iāll choose to make it my problem every time.
I donāt have to petition Webkit to change their stance or update their heuristics. If I feel strongly that a list styled without bullets should still be announced as a list, I can specificy that in the markup.
It does feel very redundant to write ul role="listā
. The whole point of having HTML elements with built-in semantics is that you donāt need to add any ARIA roles. But we did it for a while when new structural elements were introduced in HTML5āmain role="main"
, nav role="navigation"
, etc. So Iām okay with a little bit of redundancy. I think the important thing is that you really stop and think about whether something should be announced as a list or not, regardless of styling. There isnāt a one-size-fits-all answer (hence why itās nigh-on impossible to get the heuristics right). Each list needs to be marked up on a case-by-case basis.
And I wouldnāt advise spending too much time thinking about this either. There are other, more important areas to consider. Like I said, headings, forms, and images really matter. Iād prioritise those elements above thinking about lists. And itās worth pointing out that Webkit doesnāt remove all semantic meaning from styled listsāit updates the role
value from list
to group
. That seems sensible to me.
In the case of that page on The Session, I donāt think Iām guilty of listitis. Yes, there are seven lists on that page (two for navigation, five for content) but Iām reasonably confident that they all look like lists even without bullets or markers. So Iāve added role="list"
to some ul
elements.
As with so many things related to accessibilityāand the web in generalāthis is a situation where the only answer I can confidentally come up with is ā¦it depends.
Top comments (0)