Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
16. Accessibility in Web Standards
Hosted by Jamie White, with guest Léonie Watson.
The web couldn't exist without standards that define everything from presentation to metadata. For many millions of visually impaired users, the standards that support accessibility are just as important. Léonie Watson has been focused on accessibility for nearly twenty years. She joins us to talk about her long career in web accessibility, her involvement in the W3C, and where she believes the future of the technology is headed.
Léonie Watson does many things: she worked on overhauling the UK government's digital services, is on the W3C advisory board, acts as co-chair of the W3C web platform working group, is an advisor for Google's Accelerated Mobile Pages project, and also runs the Inclusive Design 24 conference. She also happens to be visually impaired. The show begins with how she went from drama school towards a career as a web programmer, and how she become a strong advocate for improving accessibility in web standards.
Léonie stresses that anyone can get involved in the decisions that power the web by contributing to the W3C's public conversations at GitHub. She details the lifecycle of a proposal, and highlights how considerations such as accessibility, security, and privacy are built-in. While existing standards are well-conceived for realms such as SVG, HTML, or ARIA, there are still new frontiers to work towards every year, particularly with API-driven interfaces. Léonie mentions how the interfaces for the "Internet of things" still need to make progress to ensure those devices are usable by all.
There are several tools to help software developers build more accessible systems. Chrome's Dev Tools, for example, have a suite of checks you can run on a website to grade its accessibility. Platforms such as Axe or Tenon can run automated tests as part of a CI flow to maintain high quality code before it ships. For Léonie, it's important for designers, developers, and product managers not to be overwhelmed by all the requirements and allow perfect to be the enemy of good. Even attempting inclusive design advances technology towards a much better place.
The conversation continues with some discussion on Léonie's work with TetraLogical, a consultancy focused on accessibility in emerging technologies, such as virtual reality, augmented reality, and WebXR. By setting a standard for inclusive design principles, Léonie hopes that organizations can incorporate accessibility as yet another aspect of good design, beyond just the bare minimums required by tech specs and test suites.
Links from this episode
- Nomensa and The Paciello Group are two agencies Léonie Watson worked at. Their focus is on better UX for web accessibility. She's since founded TetraLogical, which focuses on accessibility issues in emerging technologies like VR, AR, and WebXR.
- GitHub.com/W3C is the central meeting point for many of the discussions on web standards
- tink.uk is Léonie's blog, focused on accessibility in web standards
- Inclusive Design Principles is a set of guidelines on how to go above and beyond in making your site accessible
- Axe is an accessibility engine for automated web UI testing.
- Tenon is an "accessibility as a service" platform for websites.
Jamie: Hello and welcome to Code[ish]. Today we'll be talking with very special guest Léonie Watson about the web, standards, accessibility, and her incredible career. My name's Jamie and I'm on the front end engineering team at Heroku. Léonie has advised and consulted on major projects like the UK's government digital service overhaul, is on the W3C advisory board, is co-chair of the W3C web platform Working Group, is on the advisory committee for Google's Accelerated Mobile Pages project, runs the Inclusive Design 24 conference, and if all that weren't enough is also a wonderful writer and incredible public speaker. Hi Léonie. How you doing?
Léonie: Oh, much better for listening to that. Thank you Jamie.
Jamie: So I thought we could start at the beginning and learn a little about your path to technology in the web.
Léonie: And for some strange reason, which I have yet to to to figure out even to this day, not long after I started work there, they decided to open the tech support desk for 24 hours. Now, bearing in mind this was a time when hardly anybody was using the Internet, never mind at three o'clock in the morning, so working then the night shift was incredibly boring, so I taught myself HTML. CSS wasn't quite a thing when I did that. It came along about six, six months or so later I started playing around with web things. I kind of got the bug from there. Ended up with a friend and colleague looking after the company's websites, and it kind of just went from there, really.
Jamie: Yeah, wow. So this was UK Online?
Léonie: It was, yes. That's the name from the past.
Jamie: Yeah. So you say this was slightly before CSS came on the scene. Were you aware of web standards at that time?
Léonie: No, not really at all. I knew HTML was a thing, and I remember starting to hear you know about CSS and just thinking good grief that'll never take off. Which goes down with one of my other famous predictions, which is that Google will never supplant AltaVista as a search engine, so frankly don't listen to any predictions I've got make on the subject of technology ever. But no, I wasn't really at all aware of of web standards until I started to get into the accessibility field, and came across the web content accessibility guidelines.
Jamie: Okay, well maybe that's a good segue to talking about how you got involved in accessibility. What, where did your career with UK Online and the web go from this point?
Léonie: I had a bit of a hiatus in 2000, I lost my sight due to diabetic retinopathy and a largely misspent youth. So that took a couple of years to put things back together again. And I happened to answer a query on a forum for screen reader users, and it was from someone who had created a startup and they just built their first website for their first client, and they'd follow these things called the web content accessibility guidelines, but they didn't have any budget to do any actual testing with people with disabilities. And they were asking for screen reader users to help out.
Léonie: And I remember thinking, well, I used to be a web designer because the last sort of two or three years of my career, that's what I've been doing. And I definitely qualify now as a blind person who's a screen reader user. So, I sent this person an email that was Alastair Campbell who was one of the founders or is one of the founders of Nomensa, who are based in Bristol. He's now co-chair of the working group responsible for the aforementioned guidelines, and a longstanding friend. And we got talking and I started doing a little bit of consultancy work for them before joining the full team, the team fulltime in 2003, I think it was. And it's Alastair really who gave me the accessibility bug. So yeah, it was kind of an accident more than anything.
Jamie: How was it learning to use assistive technologies like screen readers?
Léonie: It's hard to answer that one because it was in amongst having to learn how to do everything again. So you know, this is a time when somebody saying, you've got to learn to read, you've got to learn to cross the road, do the grocery shopping, banking, sign checks, all those kind of things. And at the same time I realized I was going to have to, to learn how to use a computer again. Actually, the first discovery was that as a blind person, I could use a computer. That was quite a revelation.
Léonie: As far as I can remember it took me a fair while. It probably took me a few years to get up to the kind of same level of competency I think I'd probably had beforehand. I had to learn to touch type. That was another big surprise for all the years I'd spent, working and playing with computers. It turns out I'd never learned to touch type. So I had to try and learn how to do that first. That probably caused more cursing and swearing than anything. So yeah, they're not easy things to use. Screen readers. I have to say now though, that I use a tiny fraction of the capability of the screen readers have got, and I suspect that most screen reader users are the same. We just use the stuff we need to and generally ignore the rest.
Jamie: So was it quite, quite soon into working with Nomensa that you were getting involved with Web Standards?
Jamie: So we always been interested in them as a team, because there was so important to the work that we were doing both, you know, building websites and doing accessibility, consultancy at Nomensa.
Jamie: But it wasn't until, I think about 2009, that through various contacts in the industry, Alistair and I both actually got involved in the accessibility side of working groups at W3C, Alistair working on the authoring tool accessibility guidelines, and I joined what's now known as the protocols and formats that... Sorry, was known as the protocols and foremost working group. It's now accessible platform architectures, basically the working group at the W3C sort of keeps an eye on accessibility across all the other specs that the W3C produces. Not long after that, Nomensa became a W3C member, and I represented them on the W3C's advisory committee. So, as a member of the W3C, each organization has one representative on the AC, and that was really sort of the early days of it. And it's just gone from there through my move to The Paciello Group, TPG becoming a member, and me being the AC rep for them as well and on now through to my own company in the same position.
Jamie: Right. And what does it look like day to day? How much, how many, how many in person meetings are there, how many mailing lists threads do you have to reply to?
Léonie: As little or as much as you really want to get amongst as an AC rep. So, representing your organization within the W3C, there are two face-to-face meetings every year. Otherwise there's sort of mailing list, and some general kind of administrivia activity that you need to get involved in. One thing the AC does is endorse specifications before they become official W3C recommendations. So yeah, you spend a bit of time reviewing specs and offering your support, or not as the case may be. In terms of working groups, most of them work asynchronously now. A few still have regular conference calls, but most now just operate through GitHub, and issue discussions and kind of formats like that.
Jamie: I know you do you do that quite a bit of outreach on the behalf of the standards bodies and for accessibility in general. For practitioners out in the world, how does one go about getting involved in standards, and particularly accessibility standards?
Léonie: So with the W3C, certainly it's remarkably easy now where it used to be a bit more of a closed shop, because now everything is on GitHub, all the repos are open and they started to change their policies a bit more. The simplest thing is you just go to the GitHub.com/W3C, and have a look around and see what specs are there, and they've all got, you know, tons of issues that that comments are really, really welcome on. If anyone's curious in what's new and kind of a bubbling up, there is a W3C community group called the Web Platform Incubator Community Group, or ICG for short. And that's where people propose new ideas for specification. So, they haven't officially been adopted by the W3C, but they're very much under discussion. Lots of browser engineers keep an eye on that to add their opinions in. So that's quite an interesting place if you're curious about what ideas are coming out, and want to get involved in the early days discussions.
Jamie: Right. And then once the spec has been formalized and published and marked final, in terms of it actually being implemented by the various browser vendors in a way that's consistent across different screen readers, do the working groups kind of chase that up, and keep a tab on that? How does that side of things work?
Léonie: The W3C has a requirement for what it calls implementation experience. So, before a specification can become a formal W3C recommendation, every feature in the spec has to have at least two independent implementations. It doesn't mean to say that one browser has to implement the whole spec and so does another, they can be a bit more mix and match, but that every individual feature has to have at least two independent implementations.
Léonie: So that helps give you some production confidence that you know how well supported something you're about to use is going to be. In terms of things like accessibility, security, privacy, internationalization, W3C has that built into its process as part of what it calls wide review, so key points through a specifications lifecycle. There's a requirement that the spec is put out to either the working groups with those particular responsibilities for the different topics like accessibility, but also the public are invited to comment on those particular aspects of the spec as well. So, by the time a spec reaches official recommendation, it should have undergone at least two sets of review for the different horizontal disciplines.
Jamie: I see. Okay, so I'm going to put standards to one side for a moment, but I would like to return back to the point we left where you'd, I think you've moved to The Paciello Group, and I believe it's around this time that you consulted with a government digital service in the UK. I'd love to hear a little bit more about that.
Léonie: Yeah. My time at government digital service, or GDS actually overlaps between my time at Nomensa, and I've carried on doing it as I moved to TPG. It was just after the small team had been put together to build the prototype, the alpha prototype of of the Gov UK platform. They basically been given, I think it was 10 or 12 weeks and 60,000 pounds, and there were 12 of them told to go away and create this prototype for this idea of a single platform for all of central government, because there was a lot of skepticism that it could be done. And a credit to them, they produce this alpha, and it was like all alphas thrown together, but it proves the point that it was possible to do this. What was unusual about it was that it was done in public. Most people don't let there alpha products anywhere near the general public if they can help it.
Léonie: And that was really interesting, partly because it was different in that it was completely open to the public. But of course it also meant that a lot of the public who are unaware of the notion of an alpha product thought this was sort of something close to the finished idea. And there were a lot of criticisms around things like accessibility. So, they looked around for someone who could work with them to make sure that as the product evolved, they got the accessibility right, which is how I came to join the team in the last few months of 2011, when they started work on the private beta. And so I worked with Joshua Marshall who was part of the original team and he and I between us, with a lot of enthusiasm and support from the others on the team, started putting in place the accessibility pieces of the puzzle.
Jamie: To give a bit of context for folks listening to this who aren't from the UK and aren't where of what the government digital platform looks like, in 2009, 10, 11, when this project with booted up, it was as Léonie said, revolutionary that it was happening in the public. It's also excellent software, like really excellent, excellent user interfaces, fast convenience of everything that government software wasn't beforehand. And I remember at the time, once it had gone, got beyond the initial alpha stage, it's started to steadily absorb all of the best programmers in the country. So they would disappear into GDS for awhile and then reappear a few years later, or become permanent civil servants, which is interesting as well.
Léonie: Yeah, there was quite an interesting kind of sense of people who'd come in from the private sector going, what on Earth am I doing? I'm not a civil servant and going, actually this is quite enjoyable. We doing some good stuff here. So yeah, it was an interesting time in the early days for sure.
Jamie: So while that was going on, I gather you remained involved in standards and does The Paciello Group also have seats on the board, as it were.
Léonie: It was during my time at TPG that I joined the advisory board of the W3C, and that's a much smaller group, just 11 people now. And they advise the W3C on things like governance and strategy and all those bits and pieces. So yeah, I started doing that during my time at TPG. But even though I've left them now, one of my good friends and ex colleagues, Steve Faulkner 00:00:14:34 is now their advisory committee representative. So yeah, they're very much continuing the web standards work across their team as well.
Jamie: And just to again dig into standards a little more. So I mentioned this is working on specs like ARIA and the SVG spec I gather is something you've worked on. Does it kind of... Does accessibility cut through almost every spec to do with the web? Does it have limits?
Léonie: Yeah, it does have limits. So a lot of what W3C works on now are APIs, so you've got things like SVG, HTML, ARIA, which have a very direct impact on the user interface. But increasingly, we live in an API-driven web, or even digital world. So there is often less direct impact on the user interface of W3C suspects. It's not to say that they don't have some relevance. There will always be, if you use this API in the wrong way, it will have a pretty bad effect, or a pretty useful effect. But for example, that that they're doing a lot of work around automotive, internet or web of things, so although all of those things have interfaces, ultimately the APIs themselves don't necessarily have any influence over the way the interface is built.
Jamie: So let's, let's continue on the journey of your career. I'm kind of interested at this point to weave in how you started doing public speaking, because I think it seems to me that you're quite prolific at this point.
Léonie: Yes. That's the nice way of putting it. So I'd always been interested in doing that sort of thing. Back from my days doing acting and being at drama school, so I've obviously got a streak a mile wide in me that enjoys doing this kind of thing. I don't really remember where that started to come in useful in terms of public speaking. I think it was at the London web standards meetup probably a decade or so ago. I ended up doing a talk there. I don't remember now how that actually came to be, but that's the first time I can really remember going out and giving a talk at any place of note. I'd done it in a client presentations and all the rest of it to different companies and organizations that Nomensa and then TVG had been working with. But, I think that was the first sort of proper talk if you like, that I gave. So, I have those guys to thank, I guess.
Jamie: What's your process for writing these talks and then delivering them?
Léonie: Pretty much the same as it is for writing blog posts, I think. I find something that either I have repeated so often, that I get so irritated, I just think, right, I'm going to write a blog post or write a talk on it, get it out there. Or there's something where I just think, I finally think I've understood something and if only somebody had explained it to me in simple enough terms that I could have understood more easily, that would have been a good thing. And so I think I'd try and take subjects that I think are important and try and just simplify them and explain them in a way that I would have understood if I be on the receiving hand of them.
Léonie: Because there's just so much complication out there. You read articles, you listened to talks and there's so much implied knowledge. You listen to a talk on how to do X, but unless you happen to know how to use ABC and why, the talk is really hard to parse and understand. And I just, yeah, I can't be doing with that. Maybe it's because I'm lazy or maybe I'm just impatient, but I just want really simple information in simple phrases in simple terms. So that's usually what causes me to come up with an idea.
Jamie: I've seen you presented a couple of times and I notice you present with an earpiece in. Can you explain a little bit more about that process of presenting and syncing with your slides?
Léonie: Yeah, sure, it's very simple. As I click through my slides, my screen reader will read the title of the slide, so that's what I'm listening to in my earpiece, which is just enough of a kind of reminder about more or less what I should be saying at this point. It's quite prone to going catastrophically wrong, it has to be said. There is something that's a really, really bad idea about trying to give a talk when you need to listen to your screen reader yourself, and your slides contain audio and video you want the audience to hear. That tends to have quite a nasty impact on projectors and sound systems and things. So it's, yeah, it's quite prone to breaking horribly.
Jamie: So I guess this actually leads us naturally to your writing where you're also prolific, and I think your website tink.uk is... it's a really good place to get deep dives on some very detailed topics within web standards and accessibility. What's out there right now that you're looking to write about and you think needs a deeper or clearer explanation?
Léonie: Web components is probably top of my list at the moment. I'm starting to hear a lot of conversations about it, but the information that's out there is either written by the people who wrote the specifications, or implemented specifications in the browsers. With no particular discredit to them as individuals, quite often the people who know the most about things are the worst people to be trying to explain to people like me how to do these things. So I think, yeah, there's a lot of really detailed, really complex information about web components, custom elements, shadow DOM, all that stuff out there. But what we're missing for the moment is much more simple and approachable tutorials and guides. And that will come, but I'm writing a talk at the moment that that uses web components and all those things. So, I'm kind of fighting my way trying to understand it. I'm begging helped from a lot of people who are smarter than me for explanations along the way.
Jamie: That certainly sounds like a valuable resource. My impression of web components is that there are quite a lot of moving parts and it's not always clear how to put them together to meet particular ends or even necessarily what ends they are designed for.
Léonie: Yeah, absolutely. And it's not helped by the fact that there was an original version that got implemented I think in Chrome. I'm not sure too far widely beyond that. But then the spec changed pretty fundamentally. So they ended up calling that sort of version zero, and now there's a version one, which is sort of the course corrected kind of pathway. So, a lot of the articles you read and stuff, it's really hard to tell which version we're talking about, and how to get started is therefore quite difficult sometimes.
Jamie: Let's continue with your career. This brings us now to what you're doing now, which is I believe you started your own consultancy.
Léonie: Yes. So I left TPG at the end of last year. When I announced I was leaving, several people got in touch and were kind enough to suggest I could come and work with them. And the more I thought about doing that, the more I realized that I wanted to try and do something in the accessibility space that was my own, and perhaps a little bit different from from where I think the accessibility profession is at the moment, certainly in America. So I took a deep breath, and TetraLogical came into being in January and so far at least seems to be taken over okay.
Jamie: Okay. Well, give us the pitch. What's the... What sets TetraLogical apart from other things in the accessibility spaces?
Léonie: So we focused on emerging technologies as much as existing ones. So of course we've got our bread and butter, looking at websites, mobile app, accessibility, all those kind of bits and pieces.
Léonie: But we're also looking at things like voice assistant applications. You know, that's one area where everybody thinks it's really easy to create a voice interface, a conversational interface, because people talk all the time, but they're not taking into account the limitations of the technology, or the fact that actually talking is far more than just exchanging words. You know, we wave our hands, we make facial expressions. We do all sorts of things that kind of flow into a conversation. So thinking about the usability, the accessibility of those kinds of interfaces.
Léonie: Also virtual reality, augmented reality, WebXR, and that's a whole new world waiting for exploration, playing around with future possibilities. Could we get artificial intelligence to consume WebXR content, and make some sense of it, then might we need some way to have authors tag objects within a virtual reality to provide some kind of further definition.
Léonie: Working with people who are looking at, how do we do captions for deaf people, but in a 360 environment like VR or 360 video? How do you indicate the location within a 360 environment of the person who's actually talking at the current time? You can't just stick captions along the bottom of the screen. It doesn't work in that kind of environment. So there's all these challenges and possibilities that TetraLogical is very interested in the research and development of.
Jamie: Are you working with academics and startups, is it a mixture?
Léonie: Pretty much anybody who's similarly minded. One of the things that's quite important was to recognize what we could and couldn't do, and the partnerships were going to be a big part of the way the company goes forward. So, on the subject of VR, we're working with the W3C at the moment to set up an inclusive XR workshop. Hopefully that'll be later this year.
Léonie: So there's lots of organizations coming together to feed into that. I've been talking to companies in the UK and the US who create real world VR, if you like, you know, actual things you can step into, or at these put an actual headset on and go into, as opposed to the type of VR that happens in your browser. And talking about the research that they've already done into, to help make the interface more accessible for people with disabilities.
Léonie: Future if we've got time and energy we'd love to talk to some of the big AI companies, and see if we can play out that theory about whether AI can be used to do things like real time audio description in VR. So it's... a lot of it is about partnerships, conversations, working with other people, which is lovely. That gives us an opportunity to go and talk to all sorts of people, hear their ideas and keep building.
Jamie: I mean that's, it's a very optimistic outlook. It strikes me that rather than taking the attitude, that here's a new landscape of places for people to get accessibility wrong. Rather it's here's a new... here's a whole new landscape where accessibility can grow and be far better than it's ever been before.
Léonie: Absolutely. And and you know, it will go catastrophically wrong in places. Of course it will. That's the double-edged sword about the web, and all the related technologies, is the entirety of the web we know now more or less came into being because people pushed the boundaries and got stuff wrong and broke stuff, and pushed it a bit more and bent out of shape. And that's the great thing. We can do that. That's how we evolve and we change it.
Léonie: The thing we've got to get better at is trying to make it more accessible as we go along. And we are getting better at that, too. So I'm an optimist in case that wasn't obvious already. Yeah, people will get stuff wrong, but humans have always got stuff wrong. That's not going to change anytime soon, but we can keep improving, I think.
Jamie: So... And I mean this is a fascinating thread. Are there any of the, the current projects you're involved with at TetraLogical that you can tell us a bit more about?
Léonie: Yeah. I mean going off on a completely different direction of some of the stuff we're working on, is the idea of self-sustaining accessibility. So rather than coming in at the end point of a project, or a product lifecycle and telling you it's catastrophically inaccessible, we're working with organizations to actually embed accessibility properly in their organization.
Léonie: So, there's one UK financial sector organization that I'm working with at the moment, and we are helping to put all kinds of accessibility bits and pieces in place. So, training, policies, procurement, recruitment, hiring KPIs for individuals. The idea being is that eventually they'll be able to stand on their own two feet for accessibility, and like any other discipline, whether it's development, UX, interaction design, visual design, content design, it'll be a fully fledged entity within their digital team. And that's really fun, because it's... Culture shift is really hard to achieve. It takes time. But if you've got the ability to go in and try and tackle it. Much like you know, GDS did with central government, that's a really rewarding thing to be able to do.
Jamie: Right. And I suppose for lots of designers, developers, product managers out there, though we might be deeply interested in and see accessibility is a deeply important part of building applications for the web, getting started, and feeling confident that you're doing the right thing can be tricky, just because you either don't have a direct visceral experience of what it's like to use the web with a screen reader or other assistive tech where you don't know anybody who has that direct experience. But as you say, introducing that into a company so that it can spread naturally sounds like a wonderful thing for anyone to be exposed to.
Léonie: It is. And you're right, it can be scary sometimes trying to get started with accessibility. Partly I think because there's a notion that it has to be perfect because the consequences of it not being perfect are pretty dire for somebody somewhere. The counterpoint to that I guess is that perfect is the enemy of good. And actually if we could all get to good, that will be a hell of an improvement for most people with disabilities. So, just take a deep breath and, and have a go and accept that like everything else on the web, and everything else in technology, it won't be perfect. It'll be full of bugs and holes and issues, and you'll get some stuff wrong and you'll get some stuff right, and you'll learn. And that's how it will be, and it will keep going, but it does keep getting better as your experience kind of evolves and improves.
Jamie: I think this leads us naturally to talk about some of the, some of the great resources that are out there now for practitioners looking to train themselves better for accessibility. So I'm thinking particularly of things you've been involved with, like the inclusive design principles.
Léonie: Yup. So that was a set of principles I wrote with a Heydon Pickering, Henny Swan, Ian Pouncey. The idea originally was Henny's, she's very passionate about this idea that WCAG is very useful, or the web content accessibility guidelines. They're very useful, but they're very focused on technical conformance. Everything's gotta be testable. It's all about, can this be done or can it not be done? Binary pass or fail. And Henny's thing is really about lifting up accessibility and inclusive design beyond that. So she was the driver on that project and the other three of us very much share her feelings on the subject.
Léonie: So we set about trying to come up with these principles that would help anyone working on a digital project. Just think about the experience rather than technical conformance. So there's a, one of the principles, it talks about equivalent experiences. So the, the WCAG success criteria would say, if you've got a video and there's visual action taking place on screen, then the video needs to have audio description that describes the visual activity to someone who's blind and can't see the video.
Léonie: And that's fine. You could, you could produce all that and pass the technical conformance of WCAG. The inclusive design principles say, you've got to think about the nature of the audio description. I've watched a little while ago now, a Samuel L. Jackson film, and the audio description was done in a very proper British voice. So I'm on one hand, you've got this fast paced action, cursing and swearing, ass-kicking kind of video going on. And then the person describing the action on screen was just like, you know, "Mr. Jackson is just about to go and take a trolley hot pop at so and so." Yeah, of course I'm exaggerating. But there was a real disconnect between the way the audio description for blind people was done and the nature and the content of the movie.
Léonie: And so the inclusive design principles are saying is think about that, because that's really jarring. What you do want is the audio description to match the kind of genre, the atmosphere, the feel of the original content, if that makes sense. So yeah, the inclusive design principles are all about thinking about the experience as much as any need to technically conform to some, some standards or guidelines.
Jamie: Right. And I think that's particularly crucial for teams where you know, you might have a designer and a developer and a product manager coming together, and I think it's easy to fixate upon what the legal requirements are. What will WCAG AA guidelines say, and bringing it back to the experience is kind of crucial to designing something that holistically makes sense and is actually enjoyable to work on.
Léonie: Absolutely. And also recognizing that disability is actually that all of us, and inclusive design principles try to emphasize this, that you might put in place some mechanism to describe an image because there's someone like me who's blind and literally just can't see the image. But then equally, if someone is out in bright sunshine that's obscuring the screen or they've got a cracked screen on their phone or their tablet, that might obscure the image and the text description might be beneficial. Or they might have something temporary like a black eye or an eye infection that means they can't see properly. A migraine that makes your eyesight go squiffy.
Léonie: All of those things are temporary, but the net effect is pretty much the same. Whether it's the permanent thing, the temporary thing or a situational thing, the outcome is pretty much the same. For some reason, you can't see the image. And so it's just stepping up the thinking to really get away from the idea that disability is just about the wheelchair user, white cane wielder, signer who can't hear, and actually into to something, but pretty much nearly completely affects all of us, sooner or later at some point or another.
Jamie: I want to steer the conversation towards developers a little bit, who I think as you might imagine, are the primary audience of a Heroku podcast. So, with this I'd like to just talk a little about the kind of modern tool set of a web developer, and how best that can steer us towards building accessible UIs.
Léonie: So we're quite lucky now in that Chrome and Firefox in particular have just really good accessibility stuff built into their DevTools. Chrome for example, if you go into the DevTools and you check out the audits feature, you can run an audit on the paging question for security, privacy, performance, information about whether it's a progressive web app or not. And also accessibility. So although tools like that, automated tools, they don't give you a complete picture of accessibility, you still need a human for that real concrete kind of evaluation, they are really useful in the sense that you get a score out of a hundred. It guess there's something to aim for. It gives you lots of quick tips and tricks for improving what it spots is wrong. So although it's not a complete solution, even if developers can just get into the habit of running that Lighthouse audit from an accessibility point of view on the stuff their building, and making sure they consistently hit a hundred, that's a hell of a step in the right direction. And it's really quick and simple, to run that and do it.
Jamie: Yeah. If I remember correctly, that's... It uses under the hood, the axe library from DQ systems?
Léonie: It does. Yeah. It uses axe-core.
Jamie: And that's, and that's great because you can use axe in basically any context, I believe. So you know, if you're writing an app in React or Vue or Ember or whatever it might be, you can use axe in your automated test suite to audit your app at particular points for a test, and say, not only does it do the thing it's supposed to do, but is it accessible at this point?
Léonie: Yup, you can. I mean it's an API, so there are plugins that that you know, will work reasonably straightforwardly with a lot of the frameworks already. But yes, it's an API so you can, you can build it into your own build processes, write your own test suite in whatever suits you. And there are a couple of those out there. Tenon is another one that I really like. Axe is open source, Tenon isn't, but it's really reasonably priced, especially for for individual developers, which is something else I like about it. But yeah, they're really useful, and you can do things like instruct it to trigger a break point. So, it's really easy to run mobile or or different screen size testing as well, which is really useful from an accessibility point of view.
Jamie: With regard to... So you said that at some point you do need a human tester as well, and I guess this is because these tools generally work on the basis of kind of a snapshot of a website or web app in a given the state. So test it as it looks right now. But, really on any kind of website there are flows that the user goes through to achieve certain things. Do you think we'll see tools coming down the line that allow us to more rigorously test that those kind of flows are accessible? And thinking particularly about aspects like focus management, where poor focus management can lead to quite jarring experience. And it's quite hard to test for with something like axe.
Léonie: Yes, it's possible we'll see tools that will let us do things like that. I suspect we might be a little way off some of them though. So, one thing you still need a human to do is, is to work out whether the order a sighted keyboard user would use the tab key to move through the page. So, between different focusable elements like links or buttons or form fields, matches the visual presentation of the order of the content.
Léonie: So you know, for a tool to do that, it would need to be able to pass the HTML, or walk the DOM and find out what the actual physical tab order was, but then somehow correlate that to the almost certainly CSS control of visual presentation. It's not impossible. And I dare say there are people out there thinking, yeah sure we could do that, but things like that, I think they're going to take a little bit more advancements in kind of tooling before we're really at a point we can do that.
Léonie: And it's the human subjective things that are the most difficult. But, actually they're oddly enough, one of the areas where we're seeing AI start to kick in. So, my favorite example is text descriptions for images. And an automated tool can tell you whether an image has got a text description, but it can't tell you whether the descriptions any use at all. So I came across an example years ago, which is my favorite example of this, and it was a picture of the London underground map. And for some reason the person responsible for writing the text for the alt attribute had just written chickens. And so this... no idea whether they were just so ticked off with their job that day, they just thought "Damn it". Or whether they genuinely had no idea how alt texts are used. I really don't know.
Léonie: But an automated tool would've just gone, "Yup, it's got a text description, it's all good." And of course it's absolutely no use to the poor human being on the end of it other than to either bemuse or mystify them. But interestingly the screen reader I still actually use by by choice, JAWS, has just this year introduced an image recognition AI feature. So you can now pointed at an image on the web and get it to tell you what it thinks is in it. So actually if you take that to a logical conclusion, and we kind of wrapped that capability into a tool that tests for the presence of an alt attribute in a text description.
Léonie: In theory, yes. As the AI gets smarter and better, we could get to the point where we can even automate more of that kind of thing too. I think it'll take a little while though. The AI is still only as smart as the information we give it for the most part, and we're not doing terribly well being smarter at what we give it most of the time as far as I can see.
Jamie: Right. Yes. Things like a biased data sets and so forth.
Léonie: Yeah. The one that really makes me laugh is the IBM's Watson, and they decided they wanted to make it more capable of conversing in kind of vernacular and colloquial language to make it more human. So they fed it the urban dictionary and then had to wipe that from its memory a couple of days later cause he started swearing like nobody's business. Which that just appeals to me for some reason. But yeah, be careful what you feed it, I think is the lesson.
Jamie: So I think it'd be good to let the audience know where they can find you, where can find your work and where you might be even appearing in person this year.
Léonie: Oh sure. So easiest way to, to find me is on Twitter aforementioned garbage dump. I'm just @LéonieWatson. If you go hunting around for it, find my contact details on the UK sites. Follow the button for conferences, and you'll find it there.
Jamie: Oh, wonderful. Well with that, thank you again so much and hopefully see you soon in London or elsewhere.
Léonie: Welcome. Thanks Jamie.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
← Previous episode
15. Pursuing a Career in Tech
Next episode →
17. Integrating Terraform with Heroku
August 3rd, 118. Why Writing Matters for Engineers
Front-end Engineer, Heroku
Jamie is a software engineer on the team that takes care of Heroku’s Dashboard, CLI, Data Dashboard, and other UIs.
Web standards and accessibility consultant, Tetra Logical
Director of TetraLogical, member of the W3C Advisory Board and co-chair of the W3C Web Platform WG, technology writer and speaker.
More episodes from Code[ish]
Jim Jagielski and Alyssa Arvin
Jim Jagielski is the newest member of Salesforce’s Open Source Program Office, but he’s no newbie to open source. In this episode, he talks with Alyssa Arvin, Senior Program Manager for Open Source about his early explorations into open... →
Lisa Marshall and Greg Nokes
This episode of Codeish includes Greg Nokes, distinguished technical architect with Salesforce Heroku, and Lisa Marshall, Senior Vice President of TMP Innovation & Learning at Salesforce. Lisa manages a team within technology and product... →
Innocent Bindura and Greg Nokes
How do you know an application is performing well beyond the absence of crash reports? Innocent Bindura, a senior developer at Raygun, shares the company's tools and utilities, discusses the importance of monitoring P99 latency, and talks... →