This is the second part of my chat with Jon Gibbins. He suggests that the ever increasing speed of new technologies, hardware and software also increases the risk of accessibility being forgotten or left behind in the shuffle.
Transcript
Nic: Welcome to the Accessibility Rules podcast. This is episode 26. I’m Nic Steenhout, and I talk with people involved in one way or another with web accessibility. This episode has been sponsored by patrons like you. I really do appreciate your support. If you aren’t a patron yet, and you want to support the show, please visit patreon.com/steenhout. That’s P-A-T-R-E-O-N dot C-O-M forward slash S-T-E-E-N-H-O-U-T.
This is the second part of my chat with Jon Gibbins. We’re starting right where we left off last week.
What would you say your greatest achievement is in terms of web accessibility?
Jon: I don’t know if I have one. Running my own company. I now work with Grant Broome, and he’s been in the accessibility field for some time. We started Dig Inclusion together. Sorry, you can edit that out instantly if you don’t want me mentioning company names.
Nic: That’s fine.
Jon: That’s been really good, building your own company. We’re doing fairly well in the U.K. But probably mixed in with the question you asked me earlier about things that people perhaps don’t know about me. Most people probably don’t know that I’ve been running the a11y Twitter account for the last, nearly 10 years. I run it as and when life allows. Basically it’s just, for me, it was to … If I see something interesting on Twitter that is accessibility-related that I think comes from a good source and is teaching things in the right way, I will put it out on that Twitter feed and hope that other people will find it useful. I started doing that years and years ago. I think I’ve got nearly 6,000 followers on it. It’s not loads. But I enjoy doing that as and when life allows me to. I think that’s probably it.
Nic: Well, that’s pretty good. I had no idea that was you behind that account. That’s sweet.
Jon: There you go.
Nic: What’s your favorite word?
Jon: I don’t know if I have one. I was never very good at the English language when I was at school. You know, it was actually accessibility that brought me to a better understanding of language and how it is an accessibility tool or how grammar is an accessibility tool. Helping us to understand content. You know, commas and semi-colons. How to use them correctly. It’s sometimes a bit anally retentive of me, but I am a bit of a grammarphile. But when it comes to words, I don’t know. I think maybe epicaricacy is one that I use because … You may have heard of the word Schadenfreude, which is gaining pleasure from other people’s misfortunes. There is actually an English word and epicaricacy is it.
I’ve used it in one of my talks about UI failures. We sometimes see things on websites that we go, “Okay, that’s just hilarious UX or what were they thinking?” kind of thing. We gain pleasure from that. We laugh at these things. That is Schadenfreude. Well, epicaricacy. So, that’s one at least.
Nic: That’s a wonderful word. Thank you. I’ll have to add that to my list. Thank you. That’s wonderful.
Jon: If you want another one that my electronics teacher used to use all the time for bug or something’s that gone wrong. He used to call them shagnasties. He used to use them to describe like if we had something on an oscilloscope that was strange or obscure. He called that a shagnasty. That’s another word that I use sometimes, instead of bugs.
Nic: That’s wonderful. So, juicy. Jon, what’s your greatest frustration in terms of … with accessibility?
Jon: Lack of awareness. Just in general, misunderstanding of web standards. Just lack of awareness of how people with disabilities access digital content. The idea that … Like I said, I do quite a lot of work around mobile and I go into some organizations and they are astounded at what an Apple iPhone or a Google Android phone can do. They’re amazed by it. That’s great, but I think that’s probably … People find it hard to talk about disability. It’s a topic that is awkward for some people to talk about and it really shouldn’t be.
I think that, that kind of mentality or that way of looking at disability and what accessibility is, makes it a topic that is difficult to approach for some people. I don’t feel like it’s that way. Most people with disabilities I meet are quite happy to talk about their disability, as long as you just don’t make it the object of what you focus on. There is a person there, they have a disability, okay. But they want people to understand what it’s like and how they interact with the world, and how the world is disabling to them or disables them.
I think that probably one of the biggest things that I think is missing, is that lack of awareness. I kind of feel like that’s why accessibility doesn’t get thought about as part of the process and why it gets thought of at the end. And maybe that’s sometimes because of the legal stick. Trying to push people towards doing accessibility, rather than just being part of the design.
Nic: Lack of awareness is definitely something big. I was speaking with Sina Bahram a few weeks ago and he said we don’t have accessibility problems. We have an awareness problem and –
Jon: Yeah, I agree with that.
Nic: That really echoed so strongly within me. Do you think there’s a conventional wisdom about accessibility?
Jon: Well, the one that people normally talk about is, accessibility is all about blind people, right? But we know it’s not. That’s the one that comes to mind immediately.
Nic: How is it not?
Jon: Well, blindness for one thing is only part of visual impairment or vision-related disability. We talk, especially developers, many have heard of a screen reader, but they maybe don’t realize that speech output is actually used for people who have dyslexia, for example, that one technology does not equal one disability. Somebody with a disability may not just be blind, they may also be deaf, and therefore there’s deaf-blind people.
I think a lot of the technical approach to accessibility on the web is about making things compatible with technologies like screen readers and screen readers is probably one of the more advanced pieces of software for assistive technology out there. So, that’s why we focus on that, which may not be helped by bigger disability organizations like the NFB and in the U.K. the RNIB. Of course, they’re focused on people with low vision or people who have registered blind.
But it’s only one of four categories of disabilities, as such, physical disabilities. Somebody here who might have fibromyalgia, or pain-related issues, might mean that they have to take regular breaks from computers. We know that forms part of the Web Content Accessibility Guidelines. People who are deaf. People who, I don’t know … Again it’s not just a part of if somebody’s deaf or they’re not. Somebody may be hard of hearing. Some people may have been deaf since birth and consider themselves part of the deaf, capital D, Deaf community, which again is something a little bit different.
Developers, I think … Again it comes down to this lack of awareness and I can tell you those things and people start to twig and figure out this is about … Actually when I talk about the music software that I had helped develop, I talk about flexibility of UI and flexibility of interaction with whatever the software is. The more flexible your UI is, the more likely it is to be accommodating to a disability of some kind. Doesn’t matter what it is. That’s how I’ve kind of come to think of accessibility. There’s a term I’m avoiding using a lot at the moment and that’s the phrase fully accessible. Because I don’t think it’s possible to make something fully accessible. Maybe it is, but you can’t guess somebody’s disability at the other end of your website. You can’t guess what that person can or cannot do or what assistive … You can’t detect what assistive technologies they are or not using.
So, yeah. The conventional wisdom, okay. It’s about making sure that web content, things like images, are available to or are described to people who can’t see those images. But it’s so much more than that. I think that’s the best way I can think of to boil it down, is about that building flexibility. Almost all of the techniques that you can think of from the Web Content Accessibility Guidelines can almost be boiled down to that. Or multi-mode of access to content. So, by that I mean if somebody can’t see the video, well is there something key in that video that needs to described in a non-visual way?
Again, it’s down to flexibility of accessing that content. So, that’s kind of what I think about that. I don’t know if that really answers the question.
Nic: Yeah. I think it does and you bring in some interesting points. The concept of flexible UI to give people with or without disabilities the best way to reach the goal that they want to accomplish from your site or with your app. I think that’s an important point.
Jon: Yeah. Again, that comes back to talking about UX, as well. The UX has taught us to go and do user research and find out about the people that are actually using our products, and examine it in the audience and understanding them before building the product. Same thing goes for accessibility. So, yeah, I think that’s kind of tied in with that.
Nic: What’s the relationship between UI, UX and accessibility? Or what’s the line between them?
Jon: For some time, we’ve been thinking about development as being a more agile process. As part of that, we include trying to keep focus on the audience by building personas and we throw away ideas. We come up with wireframes or prototypes and then tweak them, and including users more. Accessibility can be brought into all of those spaces. Having diverse personas includes somebody with a disability; a student who has dyslexia; somebody who happens to use a wheelchair, within that research or within that possible audience for your product. Wireframing, you’re starting to think about structure and how things are laid out. And you can start thinking about accessibility there. Like form layouts can have usability.
There’s a lot of overlap between usability and accessibility. I’ve said that for years. But thinking about things like layout or forms can have an accessibility impact. Heading structure at that point. Grouping elements together. That all kind of makes sense. You can include people with disabilities in user testing. There are services out there that can help you find people with disabilities to do user testing. Incorporating that as part of your design process, and designers when it comes to visual design, thinking about or knowing or to having an understanding of different color combinations that can cause problems. Like one client of ours, they had built like a hosting dashboard for their infrastructure. That if a server was down it went red. If it was fine, it was green and had status on it. But they hadn’t tested with … They had thought about accessibility, but they hadn’t tested with people who are color blind. I think it’s one in ten men have some form of color blindness, I think the stat is. Something like that. The most common one being red-green color blindness.
So, the first night they ran this new system. They asked the guy who was manning the station, “How did it go?” Said, “It was absolutely useless to me because I’m red-green color blind and I couldn’t see the difference between the server that was up and the server that was down.” So, what can you do about that? You can add some iconography, perhaps. Just because you haven’t thought about testing with that person meant that it would … The first time somebody used it, it was useless to them. This is just an example of how you can segregate an entire … or a person entirely from a system like in just one little detail or missing one detail.
I think if you’re building accessibility and those kind of considerations into UX design and front-end development, as you start to build things through even in prototypes, not coincidentally it’s far more likely that accessibility is going to make it to the product at an acceptable level. Without trying to have to patch it up and fix it later.
Nic: Which ends up being more expensive.
Jon: Yeah, definitely, and a chore, which is what accessibility is often seen to be. We have phrases like the accessibility police and that kind of thing. I’ve never thought of myself as … I think many in our industry, accessibility consultants take a practical approach to accessibility and aren’t really there to just go around telling people off. But I think that, that kind of mentality or that idea of accessibility has come from, we’ve released this ace product, come and check it out, oh by the way can you have a quick look or cast your eye over it for accessibility issues. And we send a 40-page report back saying here’s all the accessibility issues that don’t conform to the Web Content Accessibility Guidelines. And they go, “Oh dear, okay. This is actually going to be a lot of work.” And that’s the point it seems to be a chore, which gives accessibility a bad rep.
Nic: What are the greatest challenges for our field, for the field of accessibility, moving forward?
Jon: Good question. I think that technology is moving at a greater rate. Think about ten years ago when we didn’t have these touchscreen … Well, these touchscreen devices were just coming about. Okay, that was sort of a bit of a leap in technology. Things have improved. But at this pace at which technology develops, I think accessibility has a … There’s a greater possibility of it getting lost, especially as we’re starting to move into an era where we have augmented reality, artificial intelligence, machine learning. And new JavaScript libraries coming out all the time. It’s hard enough when we had a handful of libraries. Now we’ve got all these other tools that … Some have been built with accessibility in mind, a lot haven’t. It’s been hard enough to try and convince people to have accessibility in their toolkit, in their skillset, without having so much to have to try to accommodate or to work with.
Mobile app usage is increasing all the time. It’s really great that software vendors like Apple, Google, Microsoft are becoming serious about accessibility. They’re including better assistive technology as part of their operating systems, often for free. It’s not always been that way. Historically, people have had no choice but to use specialist software, JAWS, ZoomText. The playing field’s changing. I think it’s good that these big companies have taken the responsibility, but as we know that’s often not enough. It’s smaller outfits and lone developers that are implementing websites. They have the ability to make things accessible or not. I think the same challenges are going to exist going forward. I just feel like they might be amplified. I don’t know. Maybe not. That’s probably what I think is … what I see coming.
Nic: Change of technology. But at the same time change of technology might resolve some of our issues. Take AI, for example. The ability of AI to interpret photos, so maybe we won’t actually need to spend much time or headache on alt text, for example.
Jon: For sure. The same issues exist with automated testing, in general. Anything automated. How good can the artificial intelligence get? Maybe it remains to be seen. The stuff that Facebook and the likes are doing with image recognition is really interesting and great. We might get to that kind of state in identifying text inside images and things like that. There would be definite improvements to accessibility through these changes with technology. Like the picture of a cat that can have the alternative text of dog. A cat that happens to look slightly dog-like can cause that software to go wrong. I mean, that’s a really silly example of it, but the human element is going to continue to be important. Because at the end of the day, the person at the other end of this computer is a person.
Nic: What’s the number one reason most people fail at implementing accessibility, do you think?
Jon: Depends how you look at the problem. Like we said earlier, organizations that don’t have a culture of accessibility … It just makes accessibility harder to achieve by not having that culture of accessibility or accepting accessibility as part of the development. I sound like a broken record, but I think that’s probably the number one reason that people fail with accessibility is that missing piece of the puzzle. It’s thought about too late. So, that’s organizations, but at lower level for developers or designers, probably a lack of full understanding of the person at the other end. From a technical point of view, one of the things I always teach developers is name, role, state. How an accessibility API works. It’s the very large … One of my bugbears is the … Name, role, value is the last guideline in the Web Content Accessibility Guidelines. For me as a developer, as soon as you understand how that API works, you understand what is expected from a technical standpoint, from assistive technologies.
Suddenly, many of the accessibility guidelines and the techniques start to make sense. It’s not that there’s not a willingness to make something accessible. It’s just that they might try to make something accessible using ARIA or have read an article about ARIA or even tabindex. Tabindex, I saw an article, I think it’s probably last year. It wasn’t very old. It was just plain wrong, about what to do with tabindex. I just couldn’t believe that there are still articles being written like that.
If a developer goes along and reads that, then they’re going to go, “Okay is this how you’re supposed to do tabindex?” Or if they read that and read another article that is actually correct about tabindex and how to use it, or how it can be useful, then all of a sudden you’re like, okay, which is right? How do I do it? You’re muddling through at that point. Sorry, it’s got noisy in the background. In muddling through, you try your best to make something accessible, but in the process you can quite break things by not understanding what it is you’re doing. And simply adding the role=tab to something, can break the experience for a screen reader user, if you don’t implement things correctly.
Nic: Last question for you Jon. What’s the one thing you would like people to remember about web accessibility?
Jon: Again, one of the things I say in training is … or a couple of the things I say in training … So, I’m probably breaking the question already by saying more than one thing. Accessibility, I don’t have all the answers, you do. That’s one of the things I normally say. Because no one knows your product like you know your product. It’s one of the reasons that we can’t … We can come up with design patterns and here’s how to do an accessible carousel. But as soon as you do something a little bit custom with that carousel, the accessibility that we’ve implemented in that example doesn’t necessarily make sense, all of a sudden.
As an engineer, when I did electronic engineering, I was taught that it’s not about knowing it all. It’s more about knowing the right direction to go in. Knowing your craft, understanding your tools. The rest you can look up. Of course, as soon as I just said, one of the problems is, you can look something up and get a bad resource. But it’s as much about understanding and empathizing with people as well. Accessibility is not as difficult as you probably think it is. It gets easier with experience. You don’t need to know everything. You can kind of think of it like, I guess, how I see religion. It should be more about having the right idea than about being perfect in the eyes of whatever it is.
It has more impact on people, to do something towards it than to check in with it at the end and try and pay lip service to accessibility. If you worry you’re doing it wrong, seek advice from the right places, but don’t expect to know everything. Accessibility is not a dark art, but it does take some learning. I said an awful lot of stuff.
Nic: That’s a fantastic quote. Accessibility is not a dark art. I like that.
Jon: Well, it doesn’t have to be. To some people it seems that way, but I really don’t think it is that way.
Nic: Hey, Jon, I think on that note we’re going to wrap it up. Thank you so much for your fantastic conversation. I learned a lot today and that’s always great, so thank you for being a guest on the podcast.
Jon: You’re very welcome. I hope I haven’t rambled on too much. But thanks for having me on and it’s been really nice to talk to you Nic, after knowing you for so many years. I know that this is the first time I’ve actually spoken to you.
Nic: Thank you for listening and until next week. Well, that’s all. But before I go, I want to thank my patrons once again. And remember that if you need a hand ensuring your site’s accessibility, I’m available. Contact me on my website at incl.ca