19. State of Web accessibility, ARIA in HTML, and missing UI patterns
Léonie Watson, Bruce Lawson, Vadim Makeev
- 01:21 Leonie and TetraLogical
- 06:28 State of accessibility
- 13:34 Screen readers
- 19:38 AI-generated alts
- 27:33 Specs interoperability
- 38:22 Missing UI patterns
- 49:21 State of ARIA specs
Transcript
Léonie: Is this visual as well as audio or just an audio podcast?
Vadim: Just audio.
Léonie: Okay. What do you mean I went and put my face on for nothing?
Bruce: No, no, no. Well, you look gorgeous.
Vadim: I would do it as a video thing, but here’s Bruce, so what can I do?
Léonie: Well, yeah, apparently you’ve got no clothes on, Vadders, but what can we do?
Bruce: Yes, but at least Vadim has the kind of body that is meant for naked videos, yeah?
Vadim: Yeah, Bruce is smart, I’m beautiful, so we have to…
Léonie: Great combination.
Bruce: I’ve got my face, that’s why it’s audio only.
Intro
Vadim: Hello and welcome to The F-word, the magical world of web standards, browsers and everything in between. I’m Vadim, coming to you from, yeah, pretty sunny Berlin right now.
Bruce: Very nice, I’m Bruce Lawson, coming to you from a similarly sunny but perhaps going to rain Birmingham in the United Kingdom and as is customary we have a very special guest, special guest unveil yourself.
Léonie: Hello, I’m Léonie Watson coming to you from a Bristol that can’t make its weather mind up. It’s been raining, it’s been sunny and it will probably start snowing in a minute, knowing my luck, but hello.
Bruce: Hi, Watters, thank you. I’m going to call you Watters. Yeah. I’m rude.
Léonie: Because you do.
Bruce: Because I do, yes.
Leonie and TetraLogical
Bruce: So for the uninitiated Léonie is… Well, who are you, Léonie? What do you do?
Léonie: I’m an accessibility specialist, currently one that has teamed up with some good friends from the industry to create a company called TetraLogical. And I spend a lot of my time helping big organizations, curious individuals, and anyone who’s willing to get stuck in find out more about accessibility and how to make things work mostly on the web for people with different kinds of disabilities.
Bruce: What do you do? Well, what does TetraLogical do? I mean, if I wish to hire you guys, what would I be hiring you to do? You’re like the A team, but with screen readers.
Léonie: Oh yes, we get theme tune and everything. It’s great. We do a lot of website application testing for accessibility. So, you know, does this app work? Does it conform to international guidelines? But that’s actually not the bulk of our work and it’s not the bit that interests us the most either.
We do a lot of what we call embedded accessibility or sustainable accessibility, which is essentially just consultancy at heart, but it’s nice because we really don’t know what we’re going to get involved in at the beginning of the project, and that’s exactly what it’s designed to do.
So we go in, we talk to organizations that maybe want to change things top to bottom, the whole sustainable organization for accessibility, or we work with a team that’s in a particular production phase of the lifecycle or something like that, and they’ve got accessibility challenges coming up, and they want some help just to make sure they get it right or figure out how to create patterns for new content that don’t really exist out there yet.
So pretty much anything goes in those projects and that’s what makes them the most interesting and the ones we’ve really set the company up to be able to do more of.
Vadim: I actually work for a company that started to develop its own accessibility standard across the whole company for different projects.
Currently we’re doing this with internal resources but I can imagine that at a certain point we will have to invite some company or some agency to help us because we don’t have enough experience with that, so I think it would be a good choice.
Bruce: Are you going to negotiate a discount?
Léonie: It’s great that you’re doing that in-house though, I mean that’s an amazing thing for an organization to do, but you’re right, sometimes having outside voices can really help.
I’ve long joked that the bit we never talk about in accessibility is the diplomatic service, and that’s the bit when sometimes having somebody else come in and say, “Hey, look, this is the way forward,” can kind of unpick some of the internal politics you often get and just help you sort of smooth the way sometimes.
But yeah, good luck. I hope it’s going well.
Bruce: So you don’t just, your tetrological bods don’t just sit there and copy paste from a thing saying, “This link needs to be underlined. This contrast isn’t enough”? It’s not just boring auditing stuff.
Léonie: No. I mean, as I say, we do that. We’re an accessibility company, and you can’t be one of those without doing some of that auditing kind of a stuff. But as I say, it’s not what we intended the company to do for the bulk of its time. And it’s happily four years in, turned out to be not what we’re doing for the bulk of our time. Plenty of it, but not all of it by any stretch. So it’s nice.
Bruce: You’ve been going four years, crikey.
Léonie: Four and a half. Don’t forget the half.
Bruce: So there’s money to be made in that there accessibility.
Léonie: It certainly seems to be, yes. We’re certainly ticking over. I mean, we’re small by design and that was one of the things we deliberately set out to be. There’s a lot of really good, very big accessibility companies out there in the world and they’re very good, particularly at audits.
They’ve got all sorts of tooling and infrastructure and they can churn these things out lickety-split and that’s great, but it was never really where we wanted to be in the scheme of things. So there are nine of us at the moment, we might add one or two more in the next year or so, but we certainly don’t have visions of growing much beyond sort of late teens.
20 is our theoretical kind of in our heads maximum of how many we’d like to be, but even that seems a little kind of large from where I’m sitting now. And being small is nice because we can be nimble going back to that idea if an organization comes up and says, “Hey, we’ve seen this on your website and we’ve seen that on your website and neither of it’s quite what we’re looking for, but can you…?” And it turns out quite often, yeah, we can.
We created a service to help one company who came to us saying, “Look, we want to build up an accessibility team, but we can’t because we don’t know what good people look like to hire. Can you come and help us?” And it’s like, “Oh blimey, that’s such an obvious problem. Why did we never think of that before?”
But we created a whole sort of support mechanism for them. And since then, it turns out that there’s lots of organizations out there going, “Actually, yeah, we can’t hire because we don’t know what good accessibility looks like. So can you help us do the hiring and the recruitment and the onboarding?” And that’s nice, yeah.
Bruce: For listeners, by the way, because regular listeners will know that we can see each other on video and just for context, at the moment, Léonie is sitting on a massive pile of diamonds and gold.
Léonie: I’ve borrowed your tiara though, Bruce.
Bruce: Snorting caviar through rolled up 50 pound notes as we speak.
State of accessibility
Vadim: Speaking of money you can make in accessibility, the whole accessibility industry or this part of our industry, reminds me early days of the web because there aren’t many people who know how this thing works. I remember early days of my career. There were just a few webmasters that knew how this thing actually works and were able to create some simple static websites that work at the same time in IE6 and Netscape Navigator 4 point something.
And these days we have a lot of screen readers that aren’t compatible. We have a number of specs that aren’t, well from my opinion, they aren’t mature enough to cover everything. We’re still getting there. so I get this feeling from the accessibility, am I right or I don’t know what I’m talking about?
Léonie: I think you’re right to a certain extent. Certainly, the message has changed over the years. From the late 90s, the message was very much that accessibility existed. We needed to tell people that it was a thing. And then, in the early 2000s, over the 10 or more years that followed that, the message became more about why it’s important and why you should think about it.
And now, I think we’re in a time where it’s much more about the how, which is just as well because you’re right, Vadim, stuff’s got much more complicated than it was back in the 90s when you could just chuck a bit of HTML and CSS and stick it on a server and call it done. And I think that’s a really good signal. Bruce, you’ll particularly remember this. If you go back a decade, maybe 15 years, the only place you ever really found accessibility talks was in accessibility conferences, and we were all just singing to the choir, basically.
Now, it’s really rare to go to any kind of web design dev Dev/UX conference and not find at least one, if not more, accessibility talks. And what’s even better is you find that people just giving talks on completely other subjects will quite often mention accessibility, just in passing, just on the occasional slide. But the fact that it’s sort of surfacing right the way through the industry is, I think, another good signal. But yeah, the how is still a major headache, partly because you’re right, standards aren’t always there.
Partly because I think there’s just people are out there jobbing developers, don’t don’t always have the luxury of going off and reading blog posts and doing training and taking tutorials. And the array of frameworks and platforms and compilers and transpilers and all this stuff just adds complexity. And then you go and throw accessibility on top of that. There’s a lot to think about.
Having said that, I think the industry is not doing too badly. As a screen reader user myself. I still come across websites I fundamentally can’t use, but considering the rise in complexity, I’m not seeing a major decrease in what I’m able to do. It seems to be, in my experience, at least holding fairly steady through time, which is kind of damning it with faint praise, I suppose. But I’ll take it, to be honest with you.
Bruce: So you find that even though the web’s becoming more complex because we’re doing more things on it, that actually finding a completely inaccessible, terrible website is becoming rarer? Or?..
Léonie: Yes, I think so. And it’s always the way, actually, it’s not so much finding a completely inaccessible website. It’s more often than not finding one thing on a website that’s inaccessible, but the thing that’ll just stop you in your tracks. You know, I’ve come across retail websites where I can go and browse, look at categories, find a product, decide I want the products to get in my basket. Oh wait, no. The add to basket button just doesn’t work. You’re kind of thinking.
Bruce: Arguably that’s not very clever from the company’s side. If you can’t actually add one product to the basket, you’d think somebody might have noticed that.
Vadim: They had one job.
Léonie: Right. Get me to buy stuff. Date pickers will be the death of me. I’ve lost count of the number of airlines, hotels, you know, name your thing where I’ve been able to do everything in order to make my reservation. Except choose the bloody date I want to check in or check out on. So websites as a whole sort of entity thing, I don’t remember the last time I fundamentally came across one I could not use in any way shape or form, but yeah it’s the one the one job problem that’s actually the real kicker these days.
Bruce: You’re a screen reader user, you’re completely blind aren’t you? You have to rely on the screen reader, there’s no residual vision left, but you haven’t always been blind, have you?
Léonie: No, I lost my sight about the turn of the century when I was in my mid-20s, which was a bit of a shock to the system.
Bruce: You were in your mid-20s at the turn of the century?
Léonie: I was, yes.
Bruce: Crikey!
Léonie: Almost exactly, in fact.
Bruce: You only look 30 even now. (See what I did there, folks?)
Léonie: I think you might be the one who needs the screen reader.
Bruce: Is lying to a blind guest like a bad sin?
Léonie: Well, only if you get caught, I suppose.
Bruce: Fair enough. So you use JAWS, don’t you, mostly?
Léonie: I do, yes. And I always feel slightly terrible about admitting to that.
Bruce: Why? Why is it embarrassing?
Léonie: Because of all the screen readers now, it’s the only one with a really stupid price tag attached to it. You’ve got NVDA, you’ve got Narrator that comes with Windows, you’ve got VoiceOver on whichever Apple device you happen to want to use, they’re all integrated. And NVDA particularly, it’s an open source project and as a screen reader, every bit as capable as JAWS.
The problem is I learned to use JAWS before any of those came along, and I quite frankly haven’t got the time or inclination to go and learn all the subtleties and nuances of another screen reader. I use all other screen readers pretty regularly, but with JAWS I know how to get myself out of pickles and troubles and I know all the advanced features and the esoteric bits and bobs that are sometimes quite useful.
Bruce: I get that. I mean, I suffered enormously when I had to move from Windows to Mac because just everything was different. Now I can’t imagine going back because it’s just going to take twice as long to do anything and with a screen reader which is basically your… it’s a thing that enables you for the whole digital world it’s not just web browsers is it you know you it’s your interface to everything on your computer. And you live on your computer because you’re a really not like us you’re a colossal geek. Just a rich one.
**Léonie: ** True that. Well, almost. Yeah, you’re right. When voice over (the screen reader that that’s on Apple devices) came along on the Mac, at the time there was a huge kind of swoop right across the industry. Everybody was like, “Wow, Macs are great! None of the kind of horrible problems that Windows had typically had up to that point.” And even then I just couldn’t bring myself to put the energy into learning a new OS. Now I actually think I’m quite glad I’ve stuck with Windows, but that’s another conversation.
Screen readers
Vadim: Another comparison that I have. I guess I’m in charge of comparisons this episode. I compared the old days of web development with accessibility. Now I’d like to compare browsers on different platforms to screen readers on different platforms. I remember back in 2015 or 2016 we used to have Safari on macOS. It wasn’t available on Windows or any other mobile devices. And we used to have a problem how to test it. I remember when they ported WebKit on Windows, it was a breakthrough. It improved the quality of websites for Safari drastically because a lot of developers were on Windows and they just couldn’t test it.
And these days it’s similar from my experience like I’m using Mac since 2006 or 2007. I’m a full-time macOS user and for me JAWS and NVDA are not available. From time to time I install some virtual machines and I try to do something with screen readers just to test but it doesn’t make it easier. I know that a lot of developers rely on voiceover as their only screen reader for testing and they have no idea how different screen readers are. Not just how different their interface is, so it’s hard for users to switch between them, but how different they actually support ARIA attributes, or how different they announce certain things, and how different the experience for their users.
And is it the only way to achieve a proper accessibility of a certain website to test in all three major screen readers, or is there a magic trick that would make it easier? Or we will have to have some Windows laptop next to our fancy Mac just to be able to test it?
Léonie: The answer is yes to all of the above, unfortunately. I mean, as you’re going to know, start off with just good quality code. That’s by far and away the best thing you could do for accessibility, especially screen reader accessibility. Screen readers are absolutely dependent on plain old semantic HTML. Divs and spans are our absolute worst thing you can do to us because they’re meaningless, which is why people like me are always banging on about, “Use your headings, use your button elements, use this.”
So that’s the first thing really that any developer can do before you even think about testing with anything in any browser, any screen reader. Just take a good look at your code and see what you can do to improve it. If you do get to the testing point, I don’t think you need to test with all three screen readers. I think you definitely do need to test with a screen reader on Windows and voiceover on MacOS. Just because, as you’ve noticed, they’re fundamentally so different in the way they behave, the way they work, you kind of do really need to do that.
I don’t think you need to test with JAWS and NVDA necessarily, although they, like all screen readers, do speak things a little differently and in some cases do support things a little differently. I don’t think that the differences between JAWS and NVDA are big enough to really worry about. So, you know, choose JAWS and Chrome, choose Firefox and NVDA, you know, but choose one of those screen readers and then team it up with VoiceOver.
Bruce: Are we basically testing the accessibility tree that the browser on Windows makes? So, in other words, JAWS and NVDA will pretty much read the same stuff, but if Firefox’s accessibility tree on Windows isn’t up to snuff, that’s what will be revealed, whether or not or not we’re using JAWS or NVDA. Is that what you’re saying?
Léonie: Largely, yes. I mean, the screen readers still do some stuff for themselves. It’s getting less and less as time goes by. But yeah, if you test JAWS in Chrome and JAWS in Firefox, there will periodically be some differences. But there are not that many of them, and they’re not major. A good example is SVG in Firefox. JAWS, SVG in Firefox are not friends in any way shape or form. They just don’t get on, don’t play well.
But that’s a really, really extreme example. For the most part, the differences on the windows screen readers and browsers are relatively minimal. I won’t say they’re non-existent, but they’re not too horrendous. But the problem you’ve got with relying on voiceover and Safari testing that you mentioned at the start of this question, Vadim, is it’s not only that you’re just relying on one browser and one screen reader, you’re also testing on the one browser and one screen reader that’s got of the three, the smallest market share by quite some margin.
So if we liken it back to the days when you used to have to test your CSS layouts in every browser because they all just looked a little bit wonky compared to each other, and you kind of had to do that to make sure that you hit all the browsers and that everything looked proper in each browser, it’s kind of a little bit like that. Having said that, there is also a sort of truth in don’t get too hung up on the fact that screen readers say things differently sometimes because very few of us use screen readers in a comparison sort of environment.
I use voiceover on my iPhone because I like those phones and then the accessibility is great and it works really well there. I use JAWS or NVDA on my Windows laptop, but the fact that they will do the same thing in slightly different phrases is not a thing to worry about because most screen reader users are not sitting there going, “Oh, JAWS said graphic and voiceover said image!”.
We kind of get the hang of that. It’s fine, but I’ve come across testing teams, dev teams get terribly worried that they all sound identical. Yeah, that’s okay. Don’t worry too much about that.
Bruce: Yeah, it’s like real human beings don’t actually sit and resize their browser windows to check if the design’s responsive. That’s something devs do.
Vadim: Really?
Bruce: I know it’s a hobby of yours over there on the rare rainy days you have in Berlin, but yeah, real humans don’t.
AI-generated alts
Bruce: So a question Watters: everybody says that we don’t have to care anymore, because AI is coming screen readers and that will magically sort out everything and it will look at our images and describe them. True or absolute bullshit?
Léonie: Absolute bullshit. Right now, anyway. I mean, I’ve had JAWS and NVDA both have image recognition API capability built into them and have done for years. And it’s excellent if you’ve got an image, particularly one that’s got text in, really, really good. Actually, that flips over more into optical character recognition OCR.
But you can get a very rudimentary understanding of what’s in an image, but it in no way shape or form does a well-crafted human text description justice. So it’s like lots of things: it’s shades of grey, isn’t it? If you’ve got an image and absolutely no way of telling what’s in it, sure, I’ll take the image recognition because it’ll at least point me in the right direction.
Given a preference, I will absolutely have a human write the text description that’s well-crafted and thoughtful and relevant to the context the image is being used in as well, because obviously image recognition APIs have no idea why the image is there. They can literally just tell you what it is. We all know that we use images for different ways and different contexts.
I wrote about this on my blog a little while ago and took a picture, I think, at one of Dali’s pictures, The Birth of Narcissus, which is one of my favorite paintings. An image recognition will basically go, “Yeah, it’s a pile of boulders.” You’re just like, “Great!”. If you knew that the picture was likely to be something related to Dali and you happened to know what Dali paintings look like, you might grasp the two pieces of information and put them together in useful ways.
And then I quote the text descriptions actually on the Wikipedia page, and it’s just a whole magnitude different.
Vadim: But at the same time, if you are looking for a picture of boulders, you can actually use this picture within different contexts. You don’t have to care that it’s a piece of art.
Léonie: Right, yeah, that’s true, absolutely.
Vadim: So it very much depends on a context.
Bruce: And it depends upon the view, doesn’t it? Somebody might want elaborate descriptions of images, or for example, imagine I’ve got a site and for whatever reason, it’s really sort of cheerful words, but I’ve surrounded it with gloomy emo imagery or something to make some kind of weird point.
You could argue that although that imagery is decorative and should have no alt text at all, for somebody who’s blind, they’re going to miss out on whatever weird point I’m making, because I haven’t described that. But other people are like, “Don’t give me lavish descriptions, just tell me the content.” And everybody’s different.
Léonie: Absolutely. I’ve been banging on about that particular thing for more years than I care to admit to. The idea that decorative images are anything that we just put up there to add a bit of atmosphere or whatever to a page should not be described has driven me to distraction for the longest amount of time because I used to be sighted. So even if I see some dreadful stock photography of a couple eating pizza on the sofa because it’s a mortgage website or something, it evokes exactly the same reaction in me as someone looking at the image.
And I suspect that As a blind person, I’m actually missing out on a lot of peculiar emo-on-a-cheerful-site imagery points to be made, and other such things. And I keep coming back to the thing you just said, Bruce. Not everybody wants to listen to that detail, but you don’t have to listen to it. If it’s there, you can skip past it, or you can stop and listen to it. If somebody decides not to put it there, that choice has gone right out of my hands.
And it’s the same. Not everybody reads every word on a webpage. I bet you all don’t. Nobody starts at the top, reads your way through the header and the navigation and t he share links and the blah blah blah. Of course you don’t. You just skim through to the bit you want and then you start, you know, start reading properly and it’s exactly the same with the screen reader.
People sort of assume that just because there’s content there, we poor souls have got to listen to every last gossip of it and believe you me, we don’t.
Bruce: It’s very common though, like when I’ve been working in a team and sort of helping newbie devs (or devs who are new to accessibility and they’re keen and they want to learn) but there’s sort of this idea that a blind person such as yourself will just sort of press a button and JAWS will just read out everything on the page and at the end of it you’re going to make your decision to go back and buy something, or hit next and then you’re going to listen to all the navigation again. There’s kind of this idea that it’s a very linear experience. But I’ve seen you using a screen reader and you’re hopping around probably more than my eyes actually are on a page.
Léonie: Yeah, but it’s the same idea. You visually scan for something that looks visually prominent, that gives you the visual clue, and then you dive in. I just do the same by navigating by headings, landmarks, whatever HTML elements seem like the most useful strategy on that particular page. But yeah, you’re absolutely right. I suspect very few of us sit and read a page from top to bottom, like it was a text file or something like that.
Bruce: We go back to the HTML then because I was going to ask you what for a blind person are the equivalent of visual cues, and then you said it’s headings and landmarks etc.
Léonie: HTML5 introduced a whole bunch of elements nav, main, header, footer, aside and such. And from a screen reader user point of view these were one of the most amazing strides forward I can remember coming across. Because up until that point there was no way to get the same experience that people have visually when you just glance at a page and you see “oh yeah I’ve got a header across the top and it’s got some nav and some search stuff in it” and then there’s “oh yeah the main content area I can see that really clearly” and “yep footer across the bottom” and you can just take it all in at a glance and there was no way really to do that with a screen reader before.
And what these elements enabled us to do is navigate between each of those blocks or landmarks on the page. So all screen readers now have a shortcut key and if you hit it you’ll go to the first of those sort of sections on the page, usually the header. If there’s a nav inside it and it’s using the nav element you’ll go to that next and each time you’ll be told what it is.
So you’ll hear header, nav, main content and it’s brilliant because usually within a matter of five or six keystrokes now you can hop all the way around the page and just get a holistic sense of the big chunks of content that are on there. So that’s one way I navigate quite readily now on pages: just, yeah, right, I’ll get to the main content area.
One of the reasons actually I do like JAWS in particular is it’s got one keystroke and it’ll take me straight to the start of the main element, so it’s basically a built-in skip link, which I would love browsers to do because then we could get rid of bloody skip links on pages. Everybody would be happy if the browsers would do it, you know, keyboard users, sighted or otherwise, could just skip straight to the main content area. It would be happiness.
TODO Vadim: As you meant that markup is correct because I personally put headers, footers, navs, asides, and mains in my code, but I don’t see it happens a lot.
Bruce: There’s a lot of them in WordPress themes though. I mean, people hate on WordPress a lot, but given that the most common themes are all mained and headed and footered up and nav’d up, and that’s 25% or something on the web, isn’t it? You’ve got a lot of bang for the buck there.
Léonie: Absolutely. And if I remember rightly, and Bruce, you’ll correct me if I’m wrong, that the whole element came around, well, all of these elements came along because there was, what was the phrase that was used at the time, “cow paths” to be paved. People were already using id=main or content or nav or navigation or something. I think there’s enough there out there in the wild to make things like that worthwhile.
Specs interoperability
Vadim: Speaking of that, in HTML right now there are like 116 or around that number HTML tags in the HTML living standard and it’s not like they say “Nav is a landmark and screen readers should show it in their menus”. No. Browsers at some point applied role navigation to nav elements and these roles are listed in another spec and the way browsers combine one spec with another one (ARIA with HTML) is totally up to them and it’s not like we can rely on it.
Not all roles available in the area spec are available in HTML. You can’t express all of them via just HTML tags you have to use ARIA attribute, I believe. We got a new <search> element recently to be able to express `role=search`` for a certain area where you can search or like filter something but it looks a bit fragile to me. Something that we cannot rely on, really. We can only test how different browsers or screen readers behave and hope for the best.
Léonie: Yeah that’s true and I think you know like any spec it takes it takes time to be implemented. I don’t think that’s anything particularly peculiar about the way ARIA or HTML are implemented in browsers, particularly. Again, going back to the HTML5 days, we saw this a lot with HTML5. Details and summary took about 10 years, I think, before all the browsers properly, A, implemented them, B, implemented the mechanics and the visual bits and pieces and C, all the accessibility.
That, again, it’s an extreme example, but I think mostly it’s about just time to implement. The other thing about a lot of this is that, to take that particular example, if you don’t have your search landmark, nothing’s going to stop. Nobody is not going to be able to access your content. A screen reader user will have several different ways to find a search field and a page within a matter of two or three keystrokes without that. So it’s also worth just thinking about, going back to the “why are you using ARIA in the first place?”, is it a blocking feature if it isn’t going to work? Is it going to stop somebody using the website or is it just going to make it easier for those using browsers and screen readers that implement it?
And I think that’s a really important part of the consideration, along with actually: should you be using ARIA at all? Because from experience the answer is almost always probably not. I’ve probably seen more websites brought down by using ARIA than I have made better for it. To be honest that’s probably one of the biggest accessibility problems I come across. People are just like “oh yeah we’ll throw some ARIA at it, It’s fine. That’ll help.” But because they don’t understand the relationship between ARIA, HTML, the browser, the accessibility tree, screen readers, and other assistive technologies with the best of intentions, it’s far, far too easy to break stuff with ARIA, unfortunately.
Bruce: I’ve certainly seen some dreadful messes made with ARIA. I kind of try and always tell people, “Unless you know what you’re doing, don’t think about ARIA.” I always think ARIA is best used in sort of ready-made components that come with frameworks and somebody knows what they’re doing, and then developers just take that off the shelf and use it.
Léonie: Yeah. I mean, the problem with a lot of the interactive roles like menu toolbar and all the rest of it is not so much that the ARIA has been used, it’s the JavaScript hasn’t been used to provide the keyboard functionality behind it. Tab panels are a great example. I find lots of beautiful sets of tab panels that tell me their tabs and there’s three tabs in the thing and it’s great until I actually try and use it. And there’s no JavaScript to give me the keyboard functionality to shift from one to the other. So yeah, you’ve got to use it sparingly and thoughtfully.
Bruce: Yeah. A lot, a lot of people don’t realize, I think that if you’re a completely blind screen reader user, you’re using the keyboard rather than a mouse or anything like that. Somebody with a visual impairment might use a screen reader, but they can also use a mouse. But you, for example, you’re not going to use a mouse because it relies on hand to eye coordination.
Léonie: Right, yeah, absolutely. Although it is worth kind of drawing a distinction, my use of a keyboard is very different to a sighted keyboard user’s. If you’re a sighted keyboard user who doesn’t use a mouse for whatever reason, you’ve got a fairly limited set of keyboard commands. You can page up, page down, tab, shift, tab, enter, space, a couple of other things besides. But because you can see what’s on screen, you don’t need keyboard commands for doing everything else.
Whereas, as a screen reader user who can’t see anything at all, I have commands, as we just chatted about, for navigating between headings, lists, landmarks, images, tables, whatever they might be, but also reading. I can say to my screen reader, “Yep, read this article from the point I’m focused on now, all the way down to the bottom,” or read it by character, or by word, or by sentence, or by paragraph, or spell this for me, or spell it in the phonetic alphabet, because all of these things.
Screen reader keyboard navigation is a fairly different beast from the way a sighted keyboard user navigates, which is something that often trips people up. I just wrote a post years ago now about how screen reader users navigate data tables, and somebody just posted a comment there recently on the video, and put it going, “But where are all the focus styles?”
It’s like there aren’t any, because I’m not tabbing between the table cells. I’m using my screen reader’s navigation to move up and down columns or left and right through rows, but that’s not the same thing as a sighted keyboard user would do to navigate, say, links or form fields or something. That comes up a lot, just not understanding the different ways that keyboard users do things, depending on with screen reader or without.
Bruce: And as well, I imagine that somebody who’s comparatively recently lost their sight and is just starting out with a screen reader is going to use it very differently from how you are, because it’s an incredibly complex bit of kit, and it must take ages to learn and become familiar with it, which is why of course you don’t want to change because now you know JAWS, there’s no point.
Léonie: Yeah, absolutely. I mean, I didn’t sit down and document it, but I imagine it probably took me two or three years before I really felt I was as capable of using a computer with my screen reader as I was when I lost my site beforehand. And then this sort of speaks back to the developer problem when you’re testing and things.
We’re expecting developers to go away and become accomplished at something that’s actually quite a complex bit of kit and then make intelligent decisions based on their experiences. And I think this is probably a big problem, why developers do their best, try something with a screen reader. Their experience is remarkably different from mine, but then they’re trying their best to make decisions based on their experiences.
And that can often lead to unintended consequences too. I don’t want to put anybody off trying to test, but I always say, have a go, keep doing it until you feel a bit more confident. And you will get there, but try not to make any big monumental decisions based on just your experiences.
Bruce: Yeah, I mean, I certainly use a screen reader once a week at least. And depending on the project I’m on and the position in the lifecycle, I might be using it for many hours each day for an extended period. And I’ve still, right next to me, you can hear rustling on my on my pinboard, I’ve still got printouts of all the keyboard shortcuts for JAWS, VoiceOver, etc, right next to me, because it’s pages and pages of stuff that I could never commit to memory.
Léonie: Oh yeah, there are certain ones I can’t ever remember. There’s a great feature in JAWS where if you’re editing a Word document, you can stick a place marker in at the point you want to start editing, and then you browse down to the point where you say you want to cut out a chunk of it, and you just move your focus there.
There’s a particular keystroke for doing that, and then just literally deleting everything between point A and point B. I can never remember what it is. I look this up about once every two weeks or so that I happen to have to use it, but back to my esoteric keyboard commands.
Bruce: Yeah, we don’t want to be… Listeners, we’re not trying to put you off testing.
Léonie: No, not at all.
Bruce: I mean, for me, what I do is I always say to people, make sure that everything has a text equivalent and make sure that everything can be reached by keyboard navigation. I don’t mean the esoteric keyboard navigation. I mean, tab and shift tab to go backwards and space or enter to activate it. And then kind of your job’s done because then it’s up to you, Léonie, how you consume that and what other magical tricks you have to go between those things. But if I haven’t exposed that stuff, you don’t have the ability at all.
Léonie: Right, absolutely. And the nice thing about testing web stuff is that in maybe five or six commands, screen reader specific navigation commands. Now you can get a really good sense of how stuff is built. The fact that every window screen reader, if you hit H, will move you to the next heading on the page. T for table if you want to do it. Just getting a handful of those under your belt and testing those and then as you say, Bruce, tabbing through things, does link text make sense and can you actually tab onto it because that’s good for me as a screen reader user but actually anybody else who isn’t using a mouse for whatever reason.
So much as screen readers are horribly complicated like OS can be. You can do a remarkable amount of testing in a fairly small number of keystrokes and as I’ve been wont to say in the past, every little helps. None of this stuff has to be perfect because nothing we ever work on on the web will ever be perfect. It just doesn’t exist.
Bruce: Excuse me?!
Léonie: Well, apart from you, Bruce.
Bruce: No, I’m talking about Vadim. Vadim is known to be perfect. He once almost murdered me in Oslo for having two spaces in a markdown file, I recall.
Vadim: Yeah, that was close.
Bruce: Do you find when you’re testing that it’s harder to test things that are native apps, things that are made with whatever you make an Android app is, or whatever you make an iPhone app? Is it harder to test?
Léonie: No, it’s not harder to test. If anything, it’s a little easier, which is going actually to the complexity of screen readers. Screen readers on touch devices are so much easier to use because the whole interface is that much simpler. Everything about it is much simpler.
So no, the testing is fine. The difference really comes for us from the professional point of view in the depth of information you can provide in the way of help. If we’ve got a problem on a website, we can dig into the code and get the dev tools out, get stuck in, and we can be reasonably prescriptive about, “Right, go here. Lose that attribute. Do that. Change the other.”
You can’t do that, obviously, with any compiled code. So with native apps and things, when we try offering help to solve things, it’s more about providing the steps to enable the developer to get to the same point you have and then kind of sort of walk that back to what they know about their code base. So that’s where it gets a little bit trickier. But no, testing itself is, if anything, probably a little easier on any kind of touch device.
Missing UI patterns
Vadim: You mentioned the summary, details like this UI pattern added to HTML a while ago. It’s been a long road to that point, but we finally have it and I see people use it a lot these days. And I think it’s better in terms of accessibility and then terrible things we used to do before that. No ARIA attributes or anything like that, but just toggling classes with JS, something like this. But we don’t have a lot of UI patterns like this on the web platforms, interactive ones.
I mean, there is a open UI working on some new primitives on the web platform, but at the moment, like to create a tabs panel, you have to write something from scratch. You don’t have, you have some attributes and some primitives in the ARIA spec, but you don’t have anything like that in the HTML spec itself. And I heard Brian Kardell working on some multiple ideas on how to bring the native tabs pattern in the web platform, but I haven’t seen any implementation so far.
And even with the tabs panel, like we implemented something like this on The F-Word website. We have show notes and transcript. These are two tabs switching between two sections. And I just went to the APG, ARIA Authoring Practices Guide, and just copy pasted the code from there. But it’s not the only version of the tab panel. I’ve seen a few of them. And it’s hard for me to tell which one is better because I open it in screen reader and it works fine and it kind of makes sense. But which one is right, which one is the best for screen reader users?
Or we need a spec, we need an opinion, we need some idea which one to choose. And how do we do that? I mean, there are many, many libraries, there are many, many patterns or implementations of the same pattern, and it’s really hard to choose.
Léonie: It is. Steve Faulkner and myself worked with Brian Karddell on the early prototypes for the native set of tab panels. Ten years ago, I think we started on that now. And yeah, you’re right, we’re not still any further forward. I think probably with that particular pattern, part of the problem Open UI has had, or any attempt to standardize it, is that it’s got too complicated too quickly.
There’s always at a point at which the conversation seems to be, “Well, a set of tab panels is almost the same as an accordion. And if we just squint at it sideways in a certain light on a Wednesday, I’m pretty sure we can come up with one set of native elements that we could just tweak so that they can do all things to all people all the time, and I kind of think that’s probably the first problem that’s blocked this for so long. If we literally just stuck to a common or garden variety set of tab panels, that might have at least unblocked one part of it.
As for your question about which is the right panel, that’s a really good example. I like the one in the APG, or at least there are two in the APG. I like the one that automatically displays the tab panel contents when you arrow through the tabs. They’ve got a second pattern where you have to actually hit enter or space or something to select the tab, in order for the the corresponding content to show up and perhaps because I remember tab panels in the analog world and that’s not really how they work you’re supposed to just choose your tab and get straight to the content. And I also find that extra keystroke just a bit too much effort to be honest.
Vadim: Yeah I think we implemented the second one so you have to use your arrows and then press space. Sorry about that.
Léonie: No, no, but it’s fine.But again, it sort of comes back to my earlier point about the search panel. It doesn’t matter which of those you choose, they’re both going to work. You know, fine, I might grumble about you making me hit an extra keystroke. The next screen reader user you ask “I’m like, oh, I love that because I don’t change the content until I decide I want to change it. So I can just hear all the different tabs by name and then I can choose the one that I want to select and have it displayed.””
This is the web. We’re humans. There probably aren’t right answers and wrong answers, and there almost certainly isn’t a single right answer or wrong answer in the scheme of things.
Bruce: You also need to be a bit careful about extrapolating from the analog world or the digital world. I know of nobody who has wallpaper on their desktop in the real world, but everybody does on their computer.
Léonie: Yeah, absolutely. And the other thing I’d say as well, just because stuff got implemented in a browser and put in a spec doesn’t mean to say it’s any better than anything else either. Look at the dialogue element, I mean the the row about where focus should go when a dialogue element opened went on for the best part of a decade, if I’m not mistaken.
And it’s just because humans have got different opinions, browser implementers have got different opinions, and we’ve all got different opinions. I think the best we can do is just expect we’ll come to the best consensus we can and try and play to the majority. While we don’t have spec stuff, then just find patterns from good sources. The APG is generally an okay source for stuff. Choosing something from theirs is almost certainly not going to be too problematic, I would have said.
Vadim: Speaking of built-in browser primitives, we were discussing earlier, I recently read an article about the form validation and it’s a common thing. Use built-in HTML stuff and you’ll get good results. But actually, it consists of two parts, we will link it to you in our show notes, definitely. And the first part teaches you how to use a native HTML validation. And it ends with paragraph. Like it’s all nice and cool, but it’s not accessible in many ways.
Like when you try to get proper error message, when you’re trying to convey important information to users, when they are filling their forms, it’s not always accessible. That’s why we’re going to turn it off, everything, all the validation and implemented via JavaScript. In this way it’s going to be much more accessible, this way it’s going to be much more reliable, and we will have more features as developers to convey proper messages during this form validation.
So do you know any other places of the web platform where we have built-in implementation in browsers apart from forms, or maybe you can you’d like to mention some specifics in the web forms, where something is an HTML spec when something is very semantic and sounds very good on paper but when it comes to implementation it’s just not usable and it’s better to reimplement it with divs, ARIA attributes and JavaScript.
Léonie: Sure, I mean date pickers, you come to mind. I haven’t checked in on the native HTML implementation in a while but I don’t expect anything has improved greatly since the last time I look. In fact a lot of the input types that came along in HTML5, they should have been really really useful things, but I think they were generally quite poorly implemented across the board. Not just from an accessibility point of view, but from all sorts.
So I suspect, yeah, if we were to look closely at the input types that are somewhat newer than the original ones, we’d find some more examples. There’s a few other things. Placeholder content has terrible color contrast, so if you’re partially-sighted, or need something to be a bit more clear, that’s a major showstopper.
The fact that the placeholder text disappears is problematic, arguably. It’s hard to know how you would do a placeholder text without having it disappear, but it’s something we should start to think about because if you’ve got cognitive disabilities that mean your short-term memory retention is problematic, and the placeholder is being used as a substitute for a label, as soon as it vanishes, that’s you screwed.
Good luck with trying to remember what you were there for the form field for.
Vadim: I used to think that I don’t have cognitive disabilities, but when I see forms coded like this, designed like this, I start thinking that I have because, or maybe everyone is like this. When you’re filling a huge form and you’re trying to check if you’re filled it correctly, if there’s no label, how would you know?
Léonie: Yeah, absolutely.
Bruce: I had the opposite because I was filling in, it might have been a Mastodon [actually, it was LinkedIn] actually, putting in some alt text on an image and I clicked into the field and still the placeholder text is there. So I tried to select it but it’s unselectable. I don’t know how it’s put there and it only disappears when you start typing but I spent a good little while trying to select it to hit the delete button.
Another example of really badly implemented good ideas was like if you have a input type equals email and you type in, you know, Bruce. And because I haven’t typed in yet, I haven’t finished typing Bruce@brucelawson.co.uk. It’s telling me incorrect. who thought to start giving error validation before I even finished bloody typing? It’s gotta be, I mean, that’s a C++ wonk who did that I’m sure because nobody like in the early days of HTML5 forms in Opera nobody really thought very much about the aesthetics or the actual usability of that stuff.
Vadim: These are usually problematic when you have I mean at least in terms of CSS as far as I understand user valid and invalid pseudo classes they used they still behave like this but what we have a pair of new user valid and user invalid and they wait for you to blur, to leave the field before showing the error.
Bruce: But that’s very recent those things, and actually that’s what it should have been in the first place. We’ve had to invent a new name that’s less intuitive because the intuitive names have implemented really badly but you can’t take them out. You can’t delete stuff. It kind of makes sense, like, valid in valid for a machine, and then user in valid in user valid for a person.
Bruce: Okay, yeah.
Léonie: But even there, you’ve still got an interesting one. So as a screen reader, you use the “I don’t know” as I move away from a field, that it’s just gone blurry. So you still need to come up with a way either, you know, I’ll submit the form and then work out why it didn’t submit and assume there’ll be some kind of error message or something, or maybe you use a live region to sort of say, “Oi! problem in the previous field or something”.
But the difficulty of that is of course, is that you do a live region that tells my screen reader to pipe up and say there was an error on the previous field. But should that override the reading of the label for the field I’ve just moved to? Or you know, what should the priority of those announcements be? And how do you handle that? Takes a bit of thinking about but yeah, visually, you’re absolutely right that that should have been how it was done originally for sure.
Bruce: I like your ARIA Live region goes “Oi!” It’s like aria-live="cockney" or something.
Léonie: This is all my coding samples I build for myself when I’m testing out stuff, things like this. None for the politeness. “Yeah. You, get back!”
State of ARIA specs
Vadim: We mentioned multiple times that a good semantic HTML is a good starting point, but at some point you have to move further, and you have to use some ARIA attributes and have to check the APG authoring practices guide or some other sources of information. You can group those together: ARIA spec + WCAG and some others into an “accessibility specs group”. What would you say about their state: how good they are right now, and if there’s if we’re missing some some major part of the of this accessibility specifications, or you’re looking forward to something new that’s coming very soon?
Léonie: That’s an interesting question. I think the ARIA spec is doing really well. I think they got handed a huge task, right about the time when web components really started emerging. And that was the trigger for the ARIA working group to start creating roles for parity with HTML.And then to your point earlier, you were saying that a lot of this isn’t implemented. You’re absolutely right.
There are roles for all kinds of text level semantics: b, em, i, whatever, and the chances of them ever actually being implemented are slim to none. There are some good use cases for them, but they’re not going to rock the world. Changes that I think we’re going to see anybody putting resources into implementing anytime soon.
But the ARIA Working Group has been valiantly working through this, and with some good effect when our screen readers are able to tell del and ins, or at least some of them, which is a huge thing that used to really drive me nuts when you go to some website and be like, “Yeah, this is discounted and you’d see the old price struck through and the new price.” And I’m just like, “I’ve got two numbers here and neither of them… What am I looking at?”
So there have been good things there. So I think the fact that the ARIA Working Group is ploughing through this is hard work, but it’s ultimately heading in the right direction and I think they’re doing a great job.
Bruce: Hear, hear. I want a good shout out for the ARIA Working Group, because I remember when Gmail had just come out and everyone was Ajaxing content in left, right and centre, because in those days the screen reader basically read out the DOM on the page load.
And if you change something afterwards, the screen reader user, well, the screen reader didn’t know, because it was a snapshot of the DOM. I remember actually getting quite depressed thinking, well, that’s it, it’s game over for accessibility on the web. And then, you know, live regions came about and this kind of stuff, and it’s not game over; it’s getting better all the time.
Léonie: Absolutely. And that was the real catalyst for screen readers to move away, as you said, from scraping the DOM to actually just querying the accessibility tree in the browser. So now actually probably the overwhelming majority of what a screen reader is able to do is based on what the browser enables it to do, if you see what I mean. So we closed that sort of dichotomy down almost entirely, which has had a huge, huge benefit, I think.
As for the APG, I have to confess I don’t really keep up so much with what’s going on there. I think there are some really good basic patterns in there. It’s always worried me slightly that none of them, or at least (this is when somebody will tell me that they’ve done this recently) as far as I’m aware they still don’t really take into consideration touch interface accessibility.
Patrick Lauke, who I know will be known to both of you and probably many people listening, has been thumping on about this one for the longest time, so there’s always a slight caution in the back of my mind about those patterns. They work great on a laptop desktop environment, but I’m much more hesitant to recommend them for something that’s going to be used on a portable device.
But having said that, yeah, there are some good things in there. And I actually like them more for their blueprints rather than the actual code examples. I wish the code was a bit more production-ready, i.e., easier to steal than it is. But that’s often the case with demo pattern-book kind of websites and stuff. But I like the information that says, “Look, this is the keyboard functionality you need to have if you’re going to develop one of these things, and these are the roles you should use and the constraints for using them.” I think that information is absolutely brilliant.
Bruce: Golden, isn’t it? I’ve used that so many times, not for the code, just for the “this is the expected keyboard interaction.” And invariably, there’s something that I hadn’t thought about or I’d forgotten. And I’m a complete genius, but even I sometimes don’t understand everything.
Vadim: At some point they created a nicely looking landing with all the information and that’s much easier to read from from my perspective at least. It used to look like a typical W3 °C spec. Not very beautiful one, and it’s hard to follow, but these days it’s hosted on GitHub. They have a really nice-looking landing and that’s easy to navigate. So if you ever checked it out before, like a few years ago, and you were disappointed, I think it might be a good chance for you to check it out again because it definitely improved.
Léonie: Great. That’s good to hear. To the rest of your question, it’s the forgotten specs in that catalogue that I think are worth mentioning. The ARIA in HTML is absolute gold dust as a spec. Steve Faulkner started it many years ago, recently stepped down as editor. Scott O’hara is now the primary editor of that.
It’s basically the rules. If you’re going to use ARIA, these are the rules you should follow. And if more people followed those rules, we would avoid many, many of the disasters that we were just chatting about earlier. It basically says if you have this type of element, you can use these roles, you absolutely must not use these roles.
These are the rules that go into a lot of the validators. AxeCore, IBM’s accessibility checker, TPG’s Arc Toolkit, they all use these rules to help you flag your usage. And so that’s the one I find myself referring to most often, along with the accessibility API mapping specs, the HTML one being the most widely used.
And this is really useful because it helps narrow down some of the oddities between different browsers and platforms and screen readers. To my earlier example of one says “graphic”, the other says “image”. This way you can find out that the accessibility APIs on one platform report this element this way and others on others will do it that way. And you can get a really good sense of what elements have got accessibility support and that’s pretty invaluable.
The one thing I do wish that some time and effort will be put into is the SVG mapping guide.I get SVG is kind of stalled at W3 °C, and so it’s no surprise really the accessibility around it has too. But it’s such a shame because there’s so much SVG out there and poised on the brink of where ARIA could be really useful with it. But a few of the pieces are missing, sadly.
Bruce: It does sound though that we’ve uncharacteristically reached a sort of rather optimistic point in our conversation. So I might actually go and start cooking my dinner cause we’re all, uh, we’re all relatively cheerful, which is unusual in the world of accessibility.
Léonie: Oh, you know me. My bit of the profession, we spent far too many years being bloody measurable to people. All the way through the 2000s, we’re telling people, “You’re doing a natural job. You can’t code. You’re going to get sued. You’re all horrible, terrible human beings. What were you thinking?” And we wondered why nobody wanted to do accessibility. And I can remember just really clearly one day going, “What the actual…? There’s got to be a better way to do this.”
Ever since then, I’ve made a concerted effort. You know what? Stuff isn’t perfect. People are trying. These days, I think they’re trying harder and more widely than ever, so let’s just keep encouraging rather than telling everybody what dreadful person you areSo yeah, I’m all for accessibility being something we should celebrate, not shy away from.
Vadim: Maybe the very last question that might turn our conversation in a different direction. The very last one, in short. Back in 2019, we talked on the Web Standard podcast about Accessibility Object Model. And speaking of specs that are moving not so fast, do you have any news like four years later?
Léonie: I don’t unfortunately. I occasionally see little flurries of discussion but no I will be open and say I’m not following it that closely, precisely because not very much was going on but no I’m not aware that there have been any particular strides forward with it. It’s a shame I think there was huge potential with that.
Bruce: Wasn’t it Alice Boxhall who was doing it? Sundress at Google, and well, she was at Google and now she isn’t, so I wonder if that’s what stalled it.
Léonie: Certainly, you know, not having her energy and input into it was one of the factors, absolutely. I think if I remember now, there were one or two technical problems that back then at least nobody could think their way out of. Privacy was part of it, and I know I was certainly one of the people raising concerns about how easy it would be to identify that someone was using a screen reader and a proxy you’d have a 90% chance of knowing they were blind or partially sighted, which is then quite personal information. But there was some more more low level primitive level security sandboxing kind of problems that came up. I forget the details now, but I know when I’m sitting in a room full of really quite talented and capable browser engineers, and they’re all stuck on the same problem, it’s a pretty gnarly problem.
Vadim: So there you have it! I managed to ruin a perfectly positive final of our episode.
Léonie: Well done.
Bruce: So, with that, with us all getting cheerful and then Vadim coming in like a big black cloud and raining all over cheerful me and Léonie, who were metaphorically licking an ice cream and hugging each other and making daisy chains. We’re going to bid farewell to our honored guest. Thank you ever so much Watters for coming in and telling us all about stuff.
Léonie: You’re very welcome. It’s always a great deal of fun chatting to the pair of you.
Bruce: Nobody ever says that to us normally, do they?
Léonie: Yeah, but cheque’s in the post, right?
Bruce: So with that gentle listeners, we will close, close the 19th edition of The F-Word. Good lord. So it’s goodbye from sunny Birmingham and from me, Bruce.
Vadim: Signing off from still sunny Berlin. And see you in the next episode. Cheers.
Bruce: Bye.