Ask Us Anything: Digital accessibility

During our latest Ask Us Anything session, questions from the community and listeners were answered in a fair bit of detail. Some wanted to know more about different types of barriers, while others wanted to understand how to test and design for accessibility.

If you’d like to listen to the session, we’ve got the full recording right here, including a full transcript below.

Full transcript of the session:

Anita: Hello everyone, and welcome to our live chat with Terry Costantino and Heather Moore. My Name is Anita Sedgwick, I run marketing here at Usability Matters, I will be hosing our Ask us Anything session today on accessibility. Excited to sit down with Terry and Heather to answer some juicy questions! We actually received a ton of questions from the audience.

Just to cover off a few administrative things before we kick off. This is being recorded, so for those of you who would like to go back and listen again, or who would like to share with friends or colleagues, it will be made available on our website,

There will be links in social media as well pointing to it.  During the session today, we will be monitoring Twitter for any additional questions, but you’ve got a panel in front of you that you can certainly use and put your questions up on that board, which we will be monitoring regularly.

All of that said, we do have a lot of questions to get to and we want to keep this session tight and keep this session as short as possible. If we don’t answer all the questions in 45 minutes we will either host another session or do a follow up blog post so please stay tuned.

Okay, without further ado, I’m going to start off with our first question.

Q:  What are some of the common barriers among people with temporary or long term disabilities including older people?

Terry: Yeah, I think that’s an excellent point actually. In a sense we all have all kinds of disabilities throughout our lives and even throughout a day. The main buckets that most accessibility consultants use are visual.

A common one that will all be familiar with, auditory, so hearing issues, cognitive, which can include dyslexia, other learning disabilities, and mobility, which can include all kinds of mobility issues including control so if control is an issue that becomes a bit more difficult as you get older. Visual also gets difficult with age, so definitely those two and auditory as well.

But as I say we all have a disability at some point so if your hands are full you have a mobility issue, it’s really hard to text if you’ve got your hands full. or if you are driving you cant look at your computer screen. Designing for accessibility is a very useful practice for making sure everyone can use your digital product, whatever it might be.

Heather: Yeah, and the web is so visual. That’s definitely one of the most common barriers people face. Not just people with vision impairments that Terry mentioned.

We are living in a mobile world and it seems like everyone has a device. In their hand at all times. So think about being outside on your phone, on a sunny day. Color contrast has a big impact on how much you can do how fast you can do it, actually. Issues around cognitive impairments like how busy a website looks or if there’s too much color contrast are often overlooked and their unfortunately not covered too well in web accessibility guidelines to when we test with users those problems come up a lot.

Q:  How can I test the accessibility of my website? 

Heather: Yeah, so when we test a website there’s typically 3 types of testing that we do.

The first being manual testing, we’ll go over a site and look for any color contrast problems, look for how the site is organized and how it’s structured. We’ll also go over the site with a screen reader to catch any issues like keyboard traps and missing form labels, and we’ll also check the overall UX in terms of how the site sounds with the screen reader as opposed to how it might look for someone. We’ll check with a speech recognition system and zooming in as well.

The second type is automated testing which means running the code through a code checker like HTML Code Sniffer. Automated code checking tools will flag any errors related to accessibility guidelines.

And the third and most important way we test is with actual users.

Accessibility testing with users is the same as usability testing; the only difference being that your users will have impairments and will be using assistive technologies (AT). And there’s so many different types of AT out there, and everyone has a different set up so that’s why testing with users is so important.

When we do manual and automated testing we catch a lot of issues but it’s difficult to catch everything. And we say this all the time; it doesn’t really matter if your site meets tech requirements if people can’t actually use it.

Q: What’s the quickest and easiest way to ensure a web is accessible would you say the automated way is the quickest way?

Heather: We hesitate to rely on automated testing it can give you a lot of false positives and it can tell you if you have a page titled but it cant tell you if its appropriate or descriptive enough. So manual testing is one of the better ways if you can’t test with users. I would favor that over automated testing for sure.

Q: How do I get started with designing an accessible website? 

Terry: There’s two situations: one might be that you are starting from scratch for a new product and there you wanna make sure that you build in accessibility right from the beginning.

During the strategy phase you want to identify the goal that you have, WCAG guidelines are the ones most commonly used. A or AA is where people are aiming, quite often we’re suggesting AA for clients, AAA is achievable but it’s a lot more difficult, so not too many of our folks are going to it at this point. So yeah at the strategy phase you’ll identify if you’ve got all the skill sets you need in house because accessibility is not one person’s job.

The person who’s writing the content, the person who’s putting alt tags on images probably should not be the developer. If you’ve got a writer, maybe it’s the writer.

The designers, both user experience and visual need to account for accessibility, and the brunt of the load lands on the developers no doubt.

But then the QA people in the tech realm need to be able to use some of the approaches that Heather just mentioned, like automated and manual checking before you put it out to users.

But then if you are going to put it out to users, you need researchers who are comfortable working with a wide range of people, some of whom may experience some of the barriers I talked about earlier. Cognitive, or mobile issues or visual issues. For a new design, getting goals in place, right up front, is the most important thing. And then making sure you’ve got that skill set all the way through.

If you’re looking at a retrofit, it’s not about starting so much with a strategy, it’s starting with an audit. That can be a more lightweight approach, or it can be quite comprehensive, and you can do it in house if you’ve got the skills or you can hire someone to do it.

But once you’ve got the audit that tells you what the problem is, then you usually need all those folks: content, design, etc to address the problems. And so, often when we do an audit for our clients we stick around to come up with the tactics that are going to get them further faster.

Heather: And just to add to what Terry said about starting from the very beginning, it’s good to involve users who might have impairments or use assistive tech in your research so interview them, include them in focus groups, consider their needs and wants form the very beginning just like you would anyone else.

And it’s also good to involve them in your personas, and that doesn’t need to be explicitly, it could be something like Tom sits at his desk by a window and has the sun glaring on his screen, or maybe he multitasks a lot and needs a design that’s not too busy and won’t distract him.

Q: Regarding assistive technologies (AT’s). What technology should be considered?

Heather: All of them should be considered. It really depends on if you’re talking about the design phase or the testing phase. During design, you should be considering all assistive tech, so think about the order of how a screen reader might go through a site, think about the labels of your buttons and your links, and the touch target sizes.

For someone who’s using speech recognition or with fine movement impairments think about how the experience might be affected if someone zoomed in 200%.

Don’t just design a site to be visually pleasing, design a site to be a pleasing experience overall, and that includes pleasing to the ears. As for testing, because there are so many different types of AT’s, and so many combinations, it’s impossible to cover them all, but you should aim for as wide a range as possible. We’ve had success recruiting participants based on impairments, rather than technology used. Quite often people will use several types, so one participant might be using 2 or more technologies, and you have a better chance of getting a wider range of devices that way. And not everyone with an impairment uses AT either, so they should be considered too. Or some of them are just using the built in capabilities as their assistive tech.

Q: What mandates and laws exist surrounding web accessibility?

Terry: There’s a few, obviously, but the good news is that the WCAG guidelines are the basis for almost all of the laws, at least the ones we’re familiar with in north America and Europe, so you may have heard of AODA, which is the legislation that governs here in Ontario. Some of the other provinces are following suit, so they’re looking to the AODA to craft their own set. But certain industries we have found also have their own guidelines so for example in the the US there is a federal guideline but then the Department of Transport has its own which is specific with its set of timelines with compliance at certain levels. So it is important to investigate multiple areas in what will apply to you, such as criteria, or meeting a compliance timeline. In that will be a level, usually WCAG that you will have to meet.

Q: What does WCAG stand for? Have they been around for a while?

Heather: It stands for Web Content Accessibility Guidelines.

Yes, they’re on version 2.0 right now, and just to add, all laws that we know of do follow the WCAG guidelines, but there usually are exceptions. AODA has exceptions around captions, around video for example that you may not need to do.

Q: You mention that you do actual testing with users with disabilities. How do you assemble a group of users with enough variation in disability or needs to adequately test a product to be accessible to as broad of an audience as possible? 

Terry: Well first, what we do with most of our accessibility testing is really just a variation on regular usability testing. It may be the same tasks, same script more or less, we do mostly one on one, so it wouldn’t be a group per se, we would recruit a number of participants and then work with them one on one.

We’ve done it a couple of ways, one is going on site with them, other is having them commit to a location, and the third is to do the testing remotely. The positive in remote testing is that they can have their own setup, which could include other people, if someone has cognitive impairment they might be joined by their caregiver, but there are downsides too.

Being with the person helps a lot in terms of really understanding what barriers the person is facing. So we have done it all those ways, as well as used a more automated approach where the folks went through the tasks alone and provided their response more in text than verbally.

Q: Is there a way to track or use analytics to see how many users get through? 

Terry: That’s a tough one. So what we say is that metrics are fantastic at pointing you in a direction, they tell you what’s going on, so if you’re discovering page drop offs, etc. It never tells you why. So that’s why we follow up with a qualitative approach where we have inklings of where the problems are, those inklings might come from the metrics, but getting side by side with users is the best way to find out.

Insights into why these issues might happen, and then sometimes it makes sense to follow up again with a more metric based approach to see if things improve when you improve something. So it’s one of those maddening UX responses of it depends, but the metrics are useful, but they won’t give you the whole story.

Q:  Specific to forms: they still use Word and PDF forms and documents, not with form fields, that we ask people to download and then fill out from our website. We can’t move away from this right now, so what suggestions would you have to do it as right as possible?

Heather: Before we get into the form, we’re talking about the interface around the form, so we need to ensure users know that the form will be a PDF that will be downloaded or that it will open in a new tab, so making that clear is important. If it does open in a new tab, you have to make sure the page has a descriptive page title.

As for the PDF itself, you need to make sure that’s accessible too. So not using a flattened image of text so someone using a keyboard or screen reader can navigate through the document. You also have to ensure the PDF is tagged so headings are headings and should be using form elements so the user can interact with a radio button or checkbox.

Make sure images have alternative text, and make sure you’re meeting color contrast. It’s also good to consider giving users additional options for the form. And this could be an HTML option but it could also be as simple as giving users an option to call in so they can fill it in over the phone, if you have the resource available.

You also have to take into consideration what happens after the user is done filling out the form, if there’s certain instructions there should be on the form so that someone doesn’t have to go back to the website to figure out next steps, they can see it right on the form.

Terry: Some of the things that Heather said there about using standard checkboxes etc go not just for forms but for web as well. So many things are really well coded and accessible if you use the standards. I think we all feel guilty about wanting to be a little fancier for the sake of it. We need to push that aside, and accessible design can still be beautiful.

We’ve got lots of great examples for how something can be beautiful, but we need to be selective about where the effort is going, and making a custom checkbox probably not the best use of anyone’s time.

Heather: We’ve done a lot of testing with the users who use AT with forms that use custom elements and they never test well. They either don’t work with a screen reader, or someone doesn’t realize that it’s a checkbox. They cause a number of problems.

Q: What are the most important things to consider if updating the design of a homepage? It seems there’s a real balance between putting too much and not putting enough on the page.

Terry: There are so many things that can happen. First of all, homepages are really important, but it’s amazing the emphasis that teams and businesses put on the homepage when lots of your folks are actually landing deep in the site from a search engine. With that said, because there’s so much competing screen real estate, a lot of folks have put carousels to get over that.

First of all, the research is in, they don’t work well for any user, but they can be especially terrible for accessibility. There is such a thing as accessible carousels, they provide good user control, they have clarity that is often missing, they don’t have images of text as Heather mentioned, they have live text to be read aloud. Carousels can be a problem.

Another thing we see very commonly is that calls to action are not unique. So if you’ve got a bunch of boxes and you want to say “Learn More” or Learn more or learn more, that’s not very useful, so for example if someone is interfacing verbally, they have a mobility issue but they’re interfacing verbally, they might say “click learn more”, but which learn more?

The system doesn’t know which one. So unique calls to action, we’ve been talking about this since the beginning of usability. It’s good for everybody, but it’s critical for accessibility. So those are a couple of things to keep in mind for the homepage.

Heather: Yeah and touching back to when we mentioned cognitive impairments, they are often overlooked and crowding your homepage is a huge killer of that. We’ve seen numerous times, and testing especially with users with cognitive impairments often have such difficulty navigating through a site that’s just too busy. More often than not, they would rather stop using this site and go to someone else if it comes down to it.

Terry: And I guess simple language, too. Simplifying the language, again, it helps everybody. Nobody wants to read through a bunch of stuff. I know people want to say so much about their products and services but cutting to the chase, what we call concision, being concise and precise is where you want to go. Less is more, and keeping the jargon to zero so that it’s very straightforward.

Q: When people are using screen readers does a screen reader literally read the page from top to bottom? And the user then has to pull out as the screen readers doing that what they’re looking for?

Heather: There are different types of ways of using a screen reader and when you’re on a page it typically will start reading the page from top to bottom, but the user can control and tab to the next element or jump around the page based on links.

Which is another reason why link contacts is so important because if someone’s jumping by links and they just here learn more learn more that’s not helpful they can just jump to headings and other elements as well.

Terry: Yeah and the screen readers themselves are a little different one to the next but how people use them is also different and one of the things I wanted to mention about the home page was getting your navigation system properly coded.

I would say it’s not a homepage issue per se, but I would say that’s very important because that’s going to affect every single page on your site, and one of the things about properly coding global navigation is the skip navigation because users don’t need to hear it at the top of every page.

And especially if you’ve got a mega nav that has maybe 1 to 3 levels we’ve seen plenty of times that it’s reading through everything every single link in that mega nav every single time they got to the top of a new page. So that would be a great use of effort.

Heather: Yes and just to add to that if you’re using a skip link make sure you QA it because we’ve seen people implement a skip link but it doesn’t actually work with screen readers or keyboards

Anita: I feel like a lot of these stories are applicable to email marketers as well.

Terry: In terms of emails themselves or driving people back to the site?

Anita: Well both when people go to the email and have to use a screen reader to read email, or when they go to the page from the email.

Terry: Well absolutely.

Q: What, if any relationship is there between responsive design and a AODA? If I want to make my website responsive what do I need to consider?

Heather: Instead of focusing on responsive, focus on general accessibility. Responsive has huge benefits for accessibility.

When you’re designing a responsive site, you really have to think about the structure and the hierarchy of each page, which can have a huge positive effect on the focus order for someone who’s using a screen reader or a keyboard for example.

Zooming in as well, if someone’s using browser settings to zoom in a responsive site will automatically adjust the layout to fit and display content properly. With a non responsive site zooming in often causes the layout to change and ways that makes it really hard to understand the actual content. With responsive you have to think about touch target as well, which benefits speech recognition users.

Speech recognition users don’t all always resort to speech to navigating the web they sometimes use a grid system, so the smaller your button is, smaller they have to make their grid and the harder it is to navigate where it is to navigate so large touch targets help with that, they also help with anyone who has fine movement impairments as well.

Also, it’s really hard to fit a lot of content on small screens. So if you have a lot of information, you really have to prioritize it. You should be cutting out a lot of things that are necessary, which really does help everyone.

Terry: That’s why some folks really love mobile first, because it forces you to make hard choices and use that concision.

Heather: And in the end it’s much better for someone using assistive technology to go through and it can have major benefits for someone with cognitive impairments.

Terry: This whole structuring of the page issue is not something many of us have thought about in the past we’ve just cared about how it looks. So why not use that heading 2 because it makes it blue and the size that I want, and not thinking about what that means to make it a heading.

There’s lots of other ways so making the structure of the site separate from the look of the site is vital and and as Heather has said responsive has helped in terms of making us all think about it that way.

The other thing is that if you’re using a robust content management system sometimes responsive and accessible are built in it doesn’t mean that you can rely on it, you still have to test it buts tart from a place where certain chunks of the page are known to be accessible and that’s really helpful. So you can get a bit of a leg up but if you’re starting from scratch, by choosing a theme that has built-in responsive and accessibility

Q: Is it possible for analytics to detect accessible technology? In other words, can they detect different operating systems?

Heather: I don’t think so there’s a lot of assistive tech that’s not necessarily tech for example, someone might be using an oversized trackball mouse, so how can you really test that. It could be hardware not software, software and not browser. So as far as we know, no.

Q:  How do you recruit users for testing based on disability?

Terry: Well with any project we collaborate with our clients about how to best find the target audiences, and it’s sometimes a combination of people that they have access to already, they might actually know their names, and sometimes we’re just sending out a call on their website asking for people who might want to participate, other times were using a professional recruiter, and hear some of the criteria does the use of assistive technology of some sort.

There’s many ways. I’m not going to say it’s easy, it’s not. It was not so much a usability test a few years ago, it was more of those haters talking about it’s important to consult people early in the strategy phase, so we recruited people through online forums with which allowed them to make their own decision about whether they want to join in, and we purposely did those remotely and asynchronously. So it wasn’t a lot of chat it was a two-day threaded discussions so that people had time to think about it and they didn’t feel pressured to answer right away and if they for whatever reason are not as fast on their device as someone might be on another device, there was no time pressure. There are ways but it’s challenging.

Q: There’s a follow up question about forms. What program or software are there to easily make accessible documents like PDF especially with header formats and tags?

Heather: Right, so there are ways to tagged PDF almost in anyway you’d create a Word document and output in Acrobat Adobe has most of those tools online as well. Terry, I don’t know if you know anymore about that.

Terry: not really. Not for forms per se, but I know HTML forms, as you said you want to use whatever is standard. But for PDF or word we don’t design them very often.

Q: It seems that error reporting is not consistent between HTML, code sniffer, etc. With results varying so much between testing tools, how can I be confident the site is accessible to the largest audience?

Heather: you’re absolutely right and that’s one of the reasons why we don’t rely on automated testing tools. Automated code checkers can give you a lot of false positive. Like I mentioned before to, it can tell you if you have a missing page title, but it can’t tell you if the title is correct and descriptive enough, and it can’t tell you if the focus order of your page make sense either, so you have to go through your site yourself and do a manual check.

I encourage everyone to learn and get comfortable with using a screen reader and try to go through the site with your eyes closed. It’s humbling quotation mark. You really want to be confident that your site is accessible. You have to test your site with your users.

Q: This listener is working at an airline in Chile. Here’s her question:
We have to make our website accessible according to the US Department of transit. We have a lot of forms and in the user test with screen readers, our users navigate the form with the arrow keys and not the top keys. Should we tell users how they have to interact with the form?

Heather: No no no no no! You should be letting users interact with the form how they choose to interact with it so if someone’s using a screen reader they should expect to use the screen reader access keys to tab to the next element then you have to let them and you can’t change that.

Q: There are a few questions are coming in around resources, guidelines, tips, best practices, testing for accessibility. I’m wondering if it’s worth addressing during the session or in the blog post?

Terry: We have a lot of resources and posts that are already on our website that are a great start. There certainly one on learning to do a lightweight audit, there’s one about that and one with resources I think but we could certainly add some. We’ve also done a previous webinar on testing with users as well, it’s also on our website. So that’s actually recorded and on our website.

Anita: We should point people to that as a follow up.

Another one came in on testing for accessibility. Specifically, to learning management systems. For example, Blackboard and Moodle. This listener would like to know if there are any best practices and resources to test these types of tools. So is there anything applicable there specifically?

Terry: The ones that I’m familiar with mostly most of them are web accessible management systems so basically the same guidelines apply to them as would apply to anything else. I myself am actually at University of Toronto. I’m using Blackboard and I have not checked it for accessibility, but I can tell you from usability standpoint it’s not great.

It’s kind of shocking that a large company with software that has such high penetration has not addressed some of those issues. I think there’s much that can be done by structuring the content on some of these sites both for usability and accessibility about her, but getting under the hood and changing the code, I’m less familiar with that.

Q: Can a person use screen reader software for their PC or do they have to learn a different access solution depending on the device?

Terry: If I understand that correctly, many computers now have a built in screen reader and our understanding is that lots of people use them for all kinds of reasons including improved accessibility, and so it’s not necessarily that they need to go to a specific screen reader, if I understand the question correctly.

Heather: Right, and how you navigate a desktop computer as opposed to how you would navigate a mobile device with a screen reader is different so in a sense they will need to learn different ways depending on the devices that they use.

Terry: One thing we also know though, and no one asks this but I’ll just blurt this out, but anyone will get used to the technology that they have, and they have their own little work-arounds and it throws us all for a loop when we see that a software has been updated, or a website gets redesigned we go: “oh wait I knew where everything was”. But it’s even worse for folks who are using assistive technologies because they might be extremely expensive and they’re not in a position to upgrade them from a financial standpoint; but also just from a learning standpoint. They don’t want to have to relearn software all the time so it’s important to understand that they may be using quite older versions of something but something like screen readers.

Q: Any thoughts on testing for cognitive accessibility?  Beyond the best practices of simplicity and content, what works best and what doesn’t when testing for cognitive accessibility?

Heather: Sure, so there isn’t really an automated test for cognitive, it’s not really something that’s measurable but we have seen in testing that low contrast isn’t just bad for someone with low vision but it’s also bad for someone with cognitive impairments.

On the opposite side of the spectrum, too much contrast such as pure white and pure black, can cause problems as well. So I’ve seen people with dyslexia might have problems reading if the contrast is too high.

Terry: That one is tough because there is such a big range of issues embedded there and the question. The asker brought up good points about the simplicity etc., but testing, not specifically with cognitive impairment.

For low literacy and for a site made for people with low literacy. We approach that design overall quite different than we approach some others and we also approach the testing a little differently because many of them have less familiarity with computers generally then we might expect in average usability tests. Understanding the audience well when you’re designing the tests is vital. And, as I said for the one where we did the online threaded discussion, it allowed for someone that needed more time or, needed to ask someone else to help them out there was a opportunity for them to do that.

Anita: Chris would like to know if we are aware of any web access solutions that integrate all access for the visually auditory cognitive challenged so that no assistive technology is needed? Are there web access solutions that integrate all of those?

Terry: Short answer is No. As we mentioned some people can use run-of-the-mill capabilities in their browsers as their assistive technology but I don’t think we can as I understand it the question correctly. I don’t think we can design a system that doesn’t require assistive technology.

 Heather: And part of the idea around assistive technology is letting someone access something the way that they want to access. It which includes their choice of screen reader or another technology. So even if they did exist, you can’t rely on that at all.

Q: Regarding forms, you know how the asterisk suggests that the field is required, our listener would like to know if you should use asterisks informs with required content.

Heather: You can, if they’re coded properly. So it needs to be a screen reader user that it is required, also you need to use a legend at the beginning of the form so the first instance of that Asterisk needs to say but it’s required. Another option for that is to just write “required” beside that form label. If most of the form elements are required you could just put in brackets optional beside the fields that are optional.

Terry: We do find that when testing and as we’ve talked people, that the asterisk is standard so lots of users look for that. It’s sort of in the back of their mind – they’re “trained.

Q: If you have to choose between making something accessible for one group at the expense of another, how do you choose?

Terry: The answer is: know your audience! I don’t know what else to say, you need to know your audience to know which one could be sacrificed.

Heather: And again that kind of goes against what accessibility is accessibility is about including all users, and if you’re explicitly cutting someone out while it goes against the definition.

 Terry: Some phrases you might have heard such as inclusive design and universal design, inclusive design is used for web and the idea that a website can be coded in a way that works well for people using all kinds of technologies. And inclusive means all of us, not just the people who may access things using adaptive technology.

Anita: It’s time! So that went rather quickly, thanks again, everybody for joining. There were a few questions that we didn’t get to.

Thank you so much for Terry and Heather for your time and Louise, working in the background furiously to make sure this all comes together seamlessly. And, finally thanks to you, our fantastic community, fantastic audience.

Please continue to send us your questions we will try to answer them. Twitter is a great place for that, and email is another way to get in touch with us. Thank you and have a fantastic rest of your day, goodbye everyone!

Error: Please enter a valid email address

Error: Invalid email

Error: Please enter your first name

Error: Please enter your last name

Error: Please enter a username

Error: Please enter a password

Error: Please confirm your password

Error: Password and password confirmation do not match