Accessibility myths 2019 – Digital Accessibility Experts Podcast 3
Stop press: Our podcasts are now available on Apple Podcasts, Spotify & Google Podcasts. Check our library of podcasts out – there’s a lot of great accessibility insight in there. And don’t forget to subscribe, so you can pick up our latest podcasts as soon as they’re out.
We’re two podcasts in now, and are really enjoying the reactions to our Digital Accessibility Experts Podcast podcast that we’re hearing out there. Happy to have your comments here too.
Having looked then at the future of accessibility last month, this time we’re going to talk about Accessibility Myths.
Back in 2011, when I was just starting Hassell Inclusion, I put up a blog trying to change some of the things people were misunderstanding about accessibility. For years it was my most popular blog. But a lot has changed in accessibility since 2011. So, in this podcast we’re bringing that up to date for 2019, touching on:
- Words don’t matter – copy is not an accessibility issue
- Blind screen reader users use the tab key all of the time
- Accessibility consultants will find exactly the same issues when reviewing the same bit of code or the same sites
- The most important accessibility is done by auditors
- Accessibility is the most important part of any digital project
- If we want to be really good at accessibility, and have reached double A, we should now go for triple A because that’s miles better
- ARIA can make anything accessible
We hope you enjoy listening to it as much as we enjoyed recording it! And if you’d prefer to read the podcast, rather than listen to it, read the transcript.
What do you think?
We’d love to know your thoughts on this podcast. Please share your comments below.
Want more?
If this has been useful, you might like to sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every month.
Transcript of audio
Jonathan Hassell: Welcome to podcast three. Slightly different people in the room with us this time, so we’ve got Graham Armfield, we’ve got Rob Wemyss and Jon Gooday. Great to have you with us, Jon. This time, we are going to be discussing accessibility myths. A few years ago I put up a blog, when I was just starting Hassell Inclusion. I just put in there a number of the things that I thought that people were misunderstanding all of the time and I wanted to just put something down to correct some of those myths that were out there.
Today we’re going to be bringing that up to date. That was 2011. I’m sure we’ve got some really great myths to try and bust today. So let’s kick off.
Rob, this was one from you, so here’s a myth: Copy is not an accessibility issue. What do you mean?
Rob Wemyss: When people think about accessibility, they often think about the technical detail – WCAG audits, making sure everything is accessible. Copy is often overlooked and it can be one of the most important things to get right, from design all the way through to actually adding the content into the site. A number of times you see people adding ‘accessibility copy’ into websites as well, where they’ve taken a ‘click here, read more’ or whatever that might be and having to embellish that with additional copy.
For me, thinking about copy upfront at the very beginning of a project is something that people should definitely be doing.
Jonathan Hassell: So words are important?
Rob Wemyss: Words are very important, yes.
Jonathan Hassell: I want more people to actually agree with us on that one. We have a very good course on accessible content, and people forget that it’s there. Yes, we’re running the developer course all of the time. Sometimes we run the QA course. We’re often running for designers. The content authors get left behind.
Jon Gooday: Yes, I definitely find, of all the disciplines involved in accessibility, the content side generally is the Cinderella. It’s the one that’s left out, or a very limited overview. Particularly from the guidelines point of view, there’s not a great deal of concreteness in the guidelines compared to things like technology requirements. One of the things is there’s a lot more that can be done around making content accessible, but we need to make that more aware so that people are aware of the benefits. Particularly people with dyslexia, for example, there’s very limited guidance specifically about how to improve the content – the visual side of content and the content itself.
There’s a whole range of things, which obviously we cover in the courses that we do. One of the things, there’s very little awareness of the key things you can do to improve the content.
Jonathan Hassell: Can anyone guess how much percentage of a website words are?
Graham Armfield: Well, it’s all of it, really, isn’t it, almost?
(Laughter)
Jonathan Hassell: All of it? Well, probably not all of it.
Jon Gooday: Maybe 90%. Let’s go for 90%, 80/90%.
Jonathan Hassell: Yes. That’s the thing, isn’t it-?
Graham Armfield: Yes.
Jonathan Hassell: … so if 90% of the website is words and WCAG doesn’t say very much about words…? It’s quite interesting. In WCAG version 1, Plain Language was single A. In WCAG 2 it’s triple A, so everyone has forgotten it. So, basically, 90% of the website the accessibility community isn’t saying very much about. Graham?
Graham Armfield: Yes, I just wanted to mention that there are tools around there, because I’ve had a lot of experience with WordPress sites over the years, building them and using them. There are some tools out there for content authors which will help them along the way. Talking about readability, there’s a plugin called Yoast, which is good for search engine optimisation. But also it has tools within there to analyse the readability of what you’re actually writing in your page and in your blog post, and what have you. People find that can be really useful because it can educate you in ways to actually make what you’re saying a lot easier to consume. There are tools out there.
I’ve also been doing a bit of work recently on a plugin with someone else to flag up if there are potentially empty headings and empty paragraphs. Which, if you’re using a content management system, it’s quite easy to leave behind, sometimes. To actually do some stuff to flag up problems like that to content authors as well. Other than that, I think there’s very little out there, especially in content management systems, that could help the content authors get around that, really.
Jonathan Hassell: Yes, I think that would be really good. Rob, you were talking the other week about using AI and things like that for not just, if you like, testing, but actually helping people who are creating stuff with some feedback. In my blog, I looked at one of the IBM tools that was trying to do that. It didn’t do a great job, but I think there are opportunities to help people on that side.
Just moving on for a second. One of the things that I put in my blog back in 2011 was that text is massively important and yet when you look at text, where it appears in WCAG, it’s all about alt-text and things like this. It feels like when you put images on a page, you need to provide alt-text if you can’t see them. If you put video on a page, you need to provide captions or transcripts because people can’t hear them or see them. If you were looking at WCAG, you’d be thinking that text, in terms of alt-text at least, was the most important thing in the universe.
I like the fact that images and videos and things like that are available. If I want to work out how to pump up the tyre of my son’s bike, I go to YouTube. I don’t go to Wikipedia. Because I’m, well, a sensible human being, I hope. It’s just an easier way of doing things. Accessibility is massively benefited by video and images and things like that and yet, again, nothing there in the guidelines about that. Anyone want to do alternative images and alternative videos, for text that we can’t understand? Any ideas?
(Silence… Laughter)
You see, it’s… That’s the point, it’s still massively contentious, that one.
Graham Armfield: I’m not sure I understand where you’re going with that, actually.
Jonathan Hassell: Well, I think the point is that, according to all of the guidelines, if I have an image, I need to make it work for people who are blind. Nobody says if I have some text, I need to make it work in another medium for people who don’t like reading text. For example, the fact that you can listen to this podcast probably makes this miles more accessible, to people who are dyslexic and don’t like text, than every other bit of content on the Hassell Inclusion website.
Graham Armfield: I agree, yes. As with tools, especially on your smartphone, people become more aware of tools, like in TalkBack, how you can get it to talk back, to read the page to you whilst you’re looking on. I consume blog posts myself when I’m walking home from the station. Just before I leave the station I set TalkBack up and get it to just read me the article as I’m walking along. It takes a bit of getting used to, but at least, then, as you’re walking, you’re consuming content at the same time.
That’s actually quite a neat way of doing it. I think, actually, other people could take advantage of that as well, really.
Jon Gooday: I think the interesting point is around how do people consume information these days. I think that’s a classic point, Graham, how we actually, day to day- actually a lot more audio stuff, a lot more video stuff compared to, traditionally, what we were doing a few years ago. The question is, how can we make use of that? Your point I think it’s valid, but maybe we need to explore it in slightly different ways. I think your point is quite radical, let me put it that way.
I think the way Graham is talking about, what tools have we got and how can we best use them now? What’s the sensible way forward for the future? I’m also thinking about, okay, big corporations will probably think, “Ooh, that’s a bit of a no-no because that’s just going to be more work.” It’s interesting. Who are we talking about? Who would we want to benefit? I think it’s really critical here. How we use stuff day to day is changing and I think that’s really important, particularly we now have audio interfaces, all that kind of stuff, artificial intelligence. What possible benefits and opportunities will that give us to provide content in a more accessible way? I think there are lots of interesting questions to explore around that.
Rob Wemyss: An interesting area I’ve been working on is within terms and conditions. The copy there tends to be very heavy, very difficult for anyone to understand.
Jon Gooday: Did you see that piece of artwork where someone took all the major social media companies and printed out the terms and conditions?
(Laughter)
They were about 20/30ft long, on a wall, literally on a wall. They’re just impenetrable for everybody.
Graham Armfield: Aren’t they supposed to be, though?
(Laughter)
Jon Gooday: That’s a very cynical perspective.
Graham Armfield: Possibly cynical.
Jon Gooday: I think there’s probably an element of lawyers want to cover themselves and their corporations, so they’ll put everything in. That’s a classic example of how do you make that easy to understand?
Jonathan Hassell: One of the myths, I guess, around that is- if you look on the W3C, so the WAI site, looking at their business cases for accessibility, one of them that you’ll find is Legal & General. That was back in 2006. I worked with the main people who worked on that. They put that out there as being ‘accessibility managed to make them huge amounts of money’. Do you know the bit of the accessibility that made them that? It was all the Plain English stuff. They basically went through all of their terms and conditions on all of those insurance things and said, “Nobody can understand these things at all. Some of the people who can’t understand them have a disability, some of them maybe have a literacy difficulty. Some of them actually have no disability at all, they just don’t want to read impenetrable legal jargon.”
I think some of the stuff on those terms and conditions, yes, again, it just proves that point that people are not thinking about accessibility when it comes to the text. And, actually, if they did do, people could make a lot of money from taking impenetrable stuff and making it easier to understand.
Jon Gooday: Absolutely.
Graham Armfield: I think the positioning of terms and conditions is an interesting one. I came across a site many years ago where the terms and conditions were within the online banking piece. A number of people who then, whilst they were consuming the terms and conditions, got timed out because they hadn’t got to the bottom of the terms and conditions before the timeout had kicked in and everything like that. It was quite frustrating. Then, eventually, we made it so that the terms and conditions were outside of the logged-in area so that people could consume it without having to log in first.
Jonathan Hassell: Cool. Let’s move on for a sec. Graham – Blind screen reader users use the tab key all of the time. Is this a myth?
Graham Armfield: Yes, actually it turns out it was. I didn’t realise. I actually follow an email forum on accessibility. It’s something that came up recently within that forum. It’s about how deep your knowledge of accessibility is and how deep your knowledge is of how assistive technologies work. It turns out that some people assumed that screen readers were using the tab key all the time when of course that’s not actually the case.
There are guidelines around tab order and keyboard operability and stuff like that and people know that, on a laptop or a desktop, if you’re using a screen reader you’re going to be interacting using key strokes to control the screen reader. I guess that people didn’t actually then think it through that, actually, of course, if you’re tabbing through the page, the only bits that you’re visiting are those things which could get focus, which means that you’re going to miss out most of the actual content or your copy on the page. If I want to read an article or a news item from a news website or something like that, the tab key is not going to be much use to me. Even finding the heading at the top of the page of the main part of that page, a tab key is not going to be able to get me there.
Apparently, people did have this myth. Of course, tabbing is useful if I’m a sighted keyboard user. Then of course I would rely on the tab to move around to things that I can interact with. Also, I would be using more the ‘up’ and ‘down’ arrow key or the ‘page down’, ‘page up’ and stuff like this to actually move around the actual content.
Jonathan Hassell: Cool. Jon?
Jon Gooday: Yes, I just wanted to touch on that. I’ve been training quite a few people recently on using screen readers. It’s that interesting gap awareness, that people do make that assumption. The first time I’ve shown people they’ve said, “Ooh, tab key,” and they’ve gone around and they’ve tried to use the tab key. There’s that gap of knowledge to know there’s a different way of doing things.
I think that’s really quite important because, fundamentally, people are not aware of how screen reader users would typically access. I think there’s a knowledge gap-
Graham Armfield: I think that’s true.
Jon Gooday: … which probably affects why people perceive that. Obviously you can tab around a page, but as you say, you miss most of the content. It’s also that mental model of people that are aware of using the keyboard, they will tab around. They’re transferring what they know and then putting it on top. There’s a gap here. How can we best address that as part of the training process that we do and making that more aware?
Graham Armfield: Yes, but certainly we demo assistive technology to people quite a lot of the time. I think that’s a revelation to a lot of people, that they’ve never seen these tools being used before. Interestingly enough, the way with the screen reader that you can, say, use the H key in JAWS and in NVDA to move to the next heading so it’s easy to find the headings on a page, that facility is not available to sighted keyboard users. No browsers implement that by default, although there are some browser extensions that are coming along now. There are a couple available which actually start to give that functionality to sighted keyboard users to help them use headings and landmarks to actually move around a page. That’s quite an interesting development. That’s something that very few people know about, though, really, I think.
Rob Wemyss: Just quickly, what’s the best way, then, to help people auditing a website? Is it a test script that gives them a more real use of how somebody is going to use that?
Jon Gooday: I think so. We’d need to simplify it, but yes, I think there’s probably a fairly good set pattern of things to try out. I would just say one thing to be aware of, there’s a whole range of knowledge and experience within the screen reader community. You’ll find that some people might use a few shortcuts and some might use all of them. We have to get a balance between that. I think, yes, we can, but we just need to be aware that different people use shortcuts in different ways.
Jonathan Hassell: Sure. Yes. In the end, it’s all about the people who actually use the tools because they need them, rather than the people who are trying to work out how people do that and the variety of people like that.
Jon Gooday: I think there’s quite a lot in the WCAG guidelines that will point to, okay, there are specific things that we can put in a script to do, but I think we just need to be aware that we’re always going to be simplifying it. I think it’s really something we do need to encourage people to do as part of testing.
Jonathan Hassell: Sure. Coming onto testing, Rob, one of the myths that you put down: Accessibility consultants will find exactly the same issues when reviewing the same bit of code or the same sites. Surely if the guidelines are great, and the methodology is right for testing things, that five different consultants, when looking at the same thing, would find the same issues. That can’t be a myth, surely?
Rob Wemyss: Surely not, but-
(Laughter)
Rob Wemyss: … even with the four of us sitting here, if we were reviewing a particular website, I’m not a gambling man, but I’d bet quite a lot of money that our reports would vary ever so slightly. Probably we’d pick up all the core issues, but there might be some stuff, which comes from experience, which is where occasionally people might get frustrated and think, “Well, why has this person found this and this other person hasn’t found that?” Is there an additional layer that we need when it comes to complicated auditing? We have a checklist. Do we need further checklists to make sure that we’re capturing as many of the issues as possible and results are consistent? Or are we ever going to get completely consistent results?
Jon Gooday: I think it’s going to be a real challenge because you’ve got human beings in the loop at the moment.
Rob Wemyss: Exactly.
Jon Gooday: There’s always going to be people will misinterpret things. They might perceive it a different way or they just might accidentally just miss the whole thing because they didn’t look- or some of the pages have been updated and they haven’t even noticed. There are lots of variables here. I’ll be honest, I’ve sat down with people and spent many hours explaining stuff to them. There’s also a knowledge gap. I’ll be honest with you, I think there is a knowledge gap in some auditors. They’re misinterpreted some guidelines. It takes time…
Part of the auditing education process is to help people understand where their misunderstandings are. There are some real classic clangers that people do, and they’ve been auditing for years. There’s a quality assurance role in this, I think. I think they’re never going to get 100%, but I think there are ways and means to improve because we do need to hit the 90% mark, definitely.
Rob Wemyss: Yes. I think prioritising issues, as well, is very, very important…
Jon Gooday: Yes, definitely.
Rob Wemyss: … because it’s our job to make sure that project teams are working on the right issues first.
Jon Gooday: Yes, I think that’s a really important point because even though we may not capture everything, thinking about the 80/20 principle, what’s the most impact to a website? Focusing on that is key and let everything else fall in its time. Yes, prioritising, I think, is a critical way to address some of this.
Jonathan Hassell: We’ve trained lots of auditors. I think one of the things that we’ve really got right in our training is that our elementary audit course and the advanced audit course, both go through all of the guidelines. But they go through them in different levels of depth. If you like, we introduce everything so that people feel, “Yes, okay, I can do this.” Then when they go onto the advanced it’s the same stuff again, but we do the, “Yes, but… yes, but… yes, but…” I guess, it feels like what we’re saying is that doesn’t end at the end of the training. That goes all the way through.
Jon Gooday: To me, there’s always a spiral. You learn enough and then you do another spiral of depth. Then it keeps going, and new stuff comes in. I don’t think anybody should assume that they know everything. It’s never going to happen.
Graham Armfield: I think it’s a case of pragmatism, as well, when you’re doing an audit because you could literally go dotting the Is and crossing the Ts and stuff like that on an audit and you’d end up with a massively long report. Sometimes there’s a threshold where you think that, actually, something is significant enough to actually make it an issue or whether it’s actually quite a minor problem, really, and in the scheme of things it’s-
Jon Gooday: Yes, and there’s some human judgement in there.
Graham Armfield: Yes, subjective, isn’t it?
Jon Gooday: I think sometimes we do audits and the sites have so many issues, we just need to prioritise 10 things, otherwise they’re never going to read the report.
Jonathan Hassell: Yes. On the other side of that, so Graham and I were in Hong Kong and China training last week. I had a bunch of QA testers who I was training. They were great because, really, most of them had never done any accessibility testing before. They were used to looking at performance or functionality, browser support, these sorts of things, but not accessibility. In the course of a day, we got them through to being able to, pretty reliably and actually enjoyably – people were laughing and having loads of fun actually doing this – they were able to do about, if you like, half of WCAG testing in the day, to a low level.
The thing about it was that these guys are never going to be accessibility specialists. They’re never going to be doing it as their job – “I’ll cut out everything else I’m doing. I’m just focusing on accessibility.” Yet for me, because of where they are in the process, because they’re actually quite close to the developers and the designers, they’re doing stuff early, every single one of the issues that they were finding is probably 5 or 10 times cheaper to fix than stuff that was being found by the auditors.
So here’s my myth: The most important accessibility is done by auditors. You see, I don’t think it is. I think the most important accessibility testing is actually done by the people, ideally, who create the thing themselves because they find their own problems. It’s never there in a report. They’ve just fixed it immediately or the QA has just after.
Graham: The designers and the developers you mean?
Jon Gooday: I think that’s really true, having worked with quite a lot of the teams focusing on the UX side, design side, development side. If you go through and get those people knowledge, they have enough knowledge, then it minimises the auditor’s role at the end of the process. That’s the ideal model and I think that’s a mature model. I think a lot of organisations have still got a long way to go with that, but I think the evidence is, well, anecdotal evidence at the very least, that is the way to go. It’s embedding it in the process and through the development lifecycle.
Jonathan Hassell: When I was in the room with those QAs, they almost held the auditors in this mythical- like, “Oh my God, they’re amazing and I’m just this little QA tester.” I was able to turn it around for them and say, “Actually, you have more potential of actually having impact on the quality of the accessibility of the products you’re testing than those auditors ever will have because of where they are in the process. There’s nothing bad about the auditors. They’re just too late to be as effective as the QAs. Suddenly, these guys who’d never done accessibility testing at the start of the day were coming out of it going, “I’m powerful. I can do something which is really important here.”
Graham Armfield: “I can save my organisation a lot of money.”
Jonathan Hassell: Yes, and that’s really cool. I want to pop on a little bit. Rob: Accessibility is the most important part of any digital project. Surely that’s got to be the case. It can’t be a myth-
(Laughter)
… because, otherwise, why are people listening to our podcast, if we’re not massively important to a project. What do you mean?
Rob Wemyss: Well, of course we are, but delivering a digital project, obviously there are lots of different components to that, accessibility being one part of that. It’s quite easy to get into the mind-set of, “Why haven’t they got this right? We’re the most important thing at this point.” We have a lot of other considerations, security being one, that the product is not going to get released if they don’t meet all the security criteria. Sometimes, for accessibility, companies will push a product live. They’ll take that risk rather than, when it comes to security, “We’re not going to go live at all.”
There’s lots of other evidence in a digital project as well. Accessibility is very, very important. But sometimes it’s not the most important thing when it comes to delivery.
Jon Gooday: I think it needs to be seen as a whole. All the elements in a good enough state.
Jonathan Hassell: Yes. I think part of it is also respect. One of the great things about most of us is we’ve not just done accessibility in our careers. We appreciate what a designer does, in terms of design, not just whether or not that’s accessible. Actually, I think quite a number of people who are new to accessibility or maybe fresh out of university or whatever… They get taught about accessibility. They don’t actually get taught about respecting what makes a good designer, what makes a good developer. They only think that the important thing is accessibility. And, I think, actually, in the end, it makes them less effective.
One of the things that we get all of the time on our design course is where you’d have an accessibility auditor saying, “Your colours don’t pass the colour contrast. Don’t worry, you just need to tweak that colour from that hex value to that hex value.” It’s like, “You’ve just broken the brand guidelines.” (Laughter) That’s not something that any large organisation is going to thank you for. So, accessibility person, you need to actually understand how this all fits in.
Rob, are people ever going to win a fight with a brand in terms of accessibility?
Rob Wemyss: It’s a really interesting one. An organisation will pick their brand colours. On occasions, certain combinations might not work for accessibility. How do you, then, in a pragmatic way, come up with solutions that will work for both parties? So making sure brand are happy, which is not always easy to do or always achievable, but then being able to fight your corner for all our customers as well with regards to colour contrast?
Graham Armfield: I had an example recently, a missed opportunity. I was approached to do an audit for a website that, literally, was a brand-new website, brand-new branding and everything like that. But the audit was done after the site had gone live. And the branding was a real problem in that it was light greens on white and stuff like this. It was really hard to read a lot of the stuff, because it was done with such poor colour contrast going on.
Obviously I reported that back, but then that gives the company a real challenge because they’ve chosen these colours and it’s already live. Presumably, there are other materials that they publish that go with that. It presents them with a real challenge as to how they actually then rectify that.
Rob Wemyss: It’s not just as straightforward as changing the colour-
Jon Gooday: No, it isn’t. No, because of the whole cost process.
Rob Wemyss: … when you have offline as well.
Jon Gooday: Having worked with quite a few companies, sometimes there is a big issue, but they’ll- if you’re willing to explore it longer term, but also what can be done in the short term and what can be done longer term. I think there is a dialogue here that needs to happen. It’s not, “You’re wrong.” It’s how can we take them on a journey of improving, so that they have the knowledge to understand why, but also that they can see the benefit of shifting that.
Some of the companies I’ve worked with, what they’ve done is they’ve given primary colours and secondary colours, and they’ve identified all the different combinations… All the designers have charts, so they know which colour combinations are double-A compliant, triple-A compliant, large text, small text. So, at a glance, their designers can have a better choice to be better informed about how to use certain colours. They know if they follow a certain combination, they know they don’t have to try very hard, that that will be accessible.
It’s an education piece. It’s a working-together piece. I think it’s a long-term project.
Jonathan Hassell: Yes. On triple A, because you’ve brought it up, so one of my myths: if we want to be really good at accessibility, we’ve done our double A, so we’re now going to go for triple A because that’s miles better. I think that’s a myth. I think some parts of the guidelines that are just there in the triple A are massively important – I mentioned one earlier, which is Plain Language. In my mind, it’s absurd that that’s triple A. That should be A. The only reason it’s triple A is because WCAG were having worries about how people would test it. That’s how it got into that bucket not the other one. It’s not because it’s not important.
But there are some things in triple A that feel they’re not quite so important. And, also, from my perspective, where people have that enthusiasm to try and go beyond double A, the guidelines almost make it feel like: “well, that’s what triple A is there for”. If you’ve got someone who’s really enthusiastic, who’s sorted their double A already, where should they go next? How do you actually improve the accessibility of a website that’s already done double A?
Rob Wemyss: Should you be, when you get to that point, looking at then testing it with real people?
Jon Gooday: Real people, yes.
Rob Wemyss: I think real people rather than jumping ahead.
Jon Gooday: I think it’s really fundamental – and this is from my experience of UX – the benefit of user testing the range and variety. People with a range of disabilities will give so much rich insight into a website, because obviously you can technically be accessible, but actually, until you get real users in front of it, using it, you really don’t know. You don’t know what clangers might be in there, even though, technically, the site is fine, but there’s something there that has been missed. I would agree with Rob. Real users actually will be the really important area, I would suggest.
Graham Armfield: I think that’s a key aspect that gets ignored, or it’s done way too late, because it’s quite possible to do user testing when the designers are coming up with and the UX people are coming up with ideas about how these things work. Because there are tools out there which will allow you to prototype your website. That’s when the user testing should also start as well, isn’t it? Then it’s almost like user testing right at the end, is too late as well, isn’t it?
Jon Gooday: It’s a lot easier now to user test. The technology has moved on. It’s much more lightweight. You don’t have to have a whole lab because there’s…
Graham Armfield: I think that’s what scares people off a lot of the time because you’re thinking, “Wow, it’s going to cost me thousands.”
Jonathan Hassell: Yes, I can just hide behind the guidelines. It’s kind of like: “Well I did the guidelines…” It’s almost like the righteous indignation of people who do triple A. It’s like, “Well, I did triple A. I’m perfect.”
Graham Armfield: Yes. “Well, my site is WCAG 4 compliant”.
Jonathan Hassell: Yes. Absolutely.
Graham Armfield: (Laughter)
Jonathan Hassell: We need to break people out of that and actually bring it back to real people.
Jon Gooday: I think that’s the key point. Why are we doing this in the first place? So people can actually use your website. That sometimes gets lost in the technicalities of WCAG.
Jonathan Hassell: It does. Here’s another one: ARIA can make anything accessible. Is that true? And, even if it’s true, is that useful and helpful? Rob, you brought that one up, but I guess, Graham, it’s your territory. Guys, what do you reckon?
Graham Armfield: Well, I’d like to hear Rob’s comments on that one first.
(Laughter)
Rob Wemyss: That’s what I was hoping you were going to say, Graham. The reason I think this is a myth. What it’s done is almost given designers a get-out-of-jail-free card where you can design anything: “It’s okay, if we’re not using a native element, we can make it accessible using ARIA.” I’ve seen some good ARIA implementation, I’ve seen some real spaghetti code when it comes to trying to make what could be a quite simple component very, very complex. I think that, yes, ARIA should be used in certain use-cases when we can’t use the correct element, the correct HTML5 element.
Jon Gooday: I think that’s the key point – use it appropriately.
Rob Wemyss: Yes, rather than as the first thing to go to.
Jon Gooday: I think a little bit of knowledge is dangerous, so there needs to be enough education. As Rob said, if HTML5 can do it, don’t play with it. Focus on where you need to add that additional functionality.
Graham Armfield: The key thing with ARIA is, yes, it’s amazing what you can do with ARIA. There are two aspects to it, is that it’s a very, very, very picky thing, in that if you get your ARIA wrong, it can almost make things worse than if you didn’t use ARIA in the first place. Sometimes developers, it seems like they just throw a bucket load of ARIA all over their code and hope it works. Of course, not surprisingly, it’s all in the wrong place and it’s all the wrong type and everything like that.
What people struggle with, I think, the developers especially, is that it’s hard to find good patterns out there. It’s okay to say “use the native controls where you can” but everyone knows how horrible the native dropdowns are. People look for the holy grail of a good list box or combo box, that it’s much easier to style and whatever like that. It’s hard to track down good patterns. There are lots of different patterns out there, but they all seem to be different. It’s hard to know which ones the right ones are, really.
Jonathan Hassell: I think it’s also hard if you’re the product manager whose products these developers are working on to know whether or not you can trust them. Our assessments for developers, I think, are really great at this because we find people…so I’m thinking about developers’ CVs… The number of technologies that you can put on your CV – the more the better. “I’m a full stack developer. I’m better than that guy because I can do all of his stuff and I can do this ARIA thing.” That’s what people seem to do and they may not necessarily get it right all the way through.
Hey, we don’t have much longer. I’m just going to move through. Just one last one. Graham, this was you: Companies think that if they admit to accessibility failings, then people will think badly of them. Would people think badly of companies if they say, “Actually, we haven’t got everything perfect,” or is that actually a strong thing to do rather than a weak one?
Graham Armfield: I think it’s a strong thing to do. What’s disappointed everyone a lot through the years that we’ve been doing accessibility is when you go to a website’s accessibility statement, accessibility page or whatever like that, it almost never, ever gives users any useful information. It just talks about, “Oh, we’ve tested this with blah, blah, blah, blah, blah and we’ve done this, met all the WCAG2 guidelines. Here are ways you can do this, that and the other,” some little browser tweaks and stuff like that.
But, it’s just like general words on a page, really.
I think certainly users of assistive technologies will know pretty much straightaway whether a website is going in the right direction. I think companies, if they know that there are things that are wrong with their website, I don’t think, in some ways – if you actually come out and say, “Look, we know this is not right, but we’re working on it-” because I think everybody understands that you can’t can’t necessarily get it all done all at once. We talked earlier about prioritising problems. I think it’s good to actually say, “Look, we know this is wrong, but we’re working on it.” I think that shows people that they’re actually taking it seriously rather than just some bland rubbish in their accessibility statement.
Jonathan Hassell: The self-justification: “We really, really care. We’ve done this, we’ve done that.”
Graham Armfield: Exactly.
Jonathan Hassell: Yes. Well, it’s not exactly true. (Laughter) You wouldn’t say it about anything else. You wouldn’t say, “I know we’ve got a massive security breach on our website and we’ve just let your information out to loads of people out there who are going to do something awful, but we’ve done all of this work.” Yes, it doesn’t make sense.
Any final words from any of you? Any other myths that we’ve missed that you think are massively important?
Rob Wemyss: I think the one that Jon mentioned, that testing can be very complicated and expensive, is a myth that we need to do more to make sure people understand it. It’s key, really, testing your products with people.
Jon Gooday: Definitely. It’s probably a more mature approach and something organisations should work towards. I would definitely say, if they really want to make an impact, get the fundamentals right and then that will be a fantastic next stage – to really explore with users.
Jonathan Hassell: That’s cool. Graham, any other myths that we’ve missed that are massively important?
Graham Armfield: I suppose one of the things is talking about placeholders instead of labels. I think that’s something I find quite a lot. People think it’s okay, but I don’t. (Laughter)
Jonathan Hassell: In fact the people who created placeholders agree with you. I think it was even in capital letters, “PLEASE DO NOT…”
Graham Armfield: Yes, in the HTML5 spec it says so.
Jon Gooday: People will use and abuse anything that they can.
Graham Armfield: Yes. Well, designers think they’re the next big thing, don’t they?
Jon Gooday: There are ways around it. We haven’t got time to cover it today, but maybe on another podcast.
Jonathan Hassell: Maybe on another podcast. Well, thank you very much. As I say, hopefully that’s busted a few myths for you out there. Thank you so much for everyone today. There are going to be more of these podcasts coming along, so tune in next time. Yes, thank you very much, everyone. That was really great.
So hopefully you’ll have made some New Year’s resolutions. And next month we’re gonna look at the New Year’s Resolutions we would like you to have made. What you could do in your rob-role in 2019 – the one thing you could do to make the product that you make more accessible. Join us next month and we’ll tell you all then.