In this first pilot episode of the podcast, we talk with spriteCloud’s Chief Operations Officer, Martin Cunnington, and Quality Assurance Engineer, Roel Wijker, about Accessibility Testing.
It might surprise you to know that between 15-20% of people (approximately 1 billion people) have a disability of some form. Accessibility Testing helps developers ensure that their application can reach this rather larger segment of their target group. Listen to Martin and Roel talk about the impetus for accessibility testing and their experiences in testing for accessibility.
Marion: Welcome to spriteCloud’s first podcast.
According to the world bank, 1 billion people experience some form of disability. This represents 15% of the world population, one-fifth of those, or between 110 million and 190 million people experience significant disabilities. How can development teams make sure that websites and apps are accessible to this large part of the population?
That’s what we’re looking into today in spriteCloud’s first podcast. I’m Marion and two of my colleagues, Martin Cunnington who’s the COO at spriteCloud and Roel Wijker, who is part of our team of testers, are joining me to discuss accessibility testing today. What is it? Who’s it good for? Spoiler. It’s good for everybody. And how can you get started with it? That’s what we’re looking into.
You can find all the accessibility testing guidelines, we will discuss sources and additional resources on www.spritecloud.com/podcast. That is
www.spritecloud.com/podcast. So let’s dive in. Roel, Martin, can you start by introducing yourselves and telling us a little bit about your link to accessibility testing?
Roel: Yes, of course. Well, I’ll take the lead on this end. Uh, thank you. I’m Roel I’ve been working at spriteCloud for, oh, well last, two weeks ago, it was my four-year anniversary. And accessibility testing is something for me that came up during my first assignment, actually for spriteCloud.
So that will be four years ago at Tele2 where we were pointed by some customers of the product that we were working on that accessibility was nonexistent. And that’s what made us, uh, change it around real quick. But we’ll get to that later. I’ll give the word to Martin.
Martin: Thank you. My name is Martin Cunnington.
I’m a director here at spriteCloud. I’ve been working on the web. More or less since it came up. My interest in accessibility started, I think in London when I was working for an agency just around the corner, from the Royal National Institute of the Blind. So we had a connection through a very enlightened technical director.
Who invited her representative from the RNIB, to come round to have a look at our work with us. And the person came round. He was a registered blind. He had a dog, he sat at the front of the meeting room and he went through our website with us and the result was shocking.
Uh, we were flabbergasted at just how bad our designs and websites were to use if you weren’t, if you didn’t have a hundred percent vision, a hundred percent hearing, a hundred percent physical motion and so on and so forth. And we had no idea that what we were doing was so unusable to such a chunk of the world’s population, as it turned out.
So from that moment on there, it struck me that everything we did on the web should be designed from the beginning to be inclusive, not exclusive. And, that interest has been with me ever since.
Marion: Perfect. Thank you for the introduction. If you happen to research accessibility testing, you will come across something along the lines of “it’s the practice of making websites and apps usable by everyone,” as simple as that, but that doesn’t tell us how to test for accessibility.
So Roel, what do you start with when you perform accessibility testing?
Roel: Well normally. Let’s say that we were testing an app on a mobile device. I would install the app and immediately go to the device settings itself and set the font to the biggest you can find, that it can be set to, maybe even make them bold.
Sometimes you can even make them italic or change the colours to a higher contrast. And then see what the app looks like. I guarantee you that 9 out of 10 times, buttons won’t be visible anymore. They’ll be pushed out of the screen. And then the screens, they didn’t think about about this, so you can’t scroll down.
So, users will be stuck from the get-go. And when I look around. Well, my parents, a lot of parents of my friends, they all have their phones set to a bigger size. So that’s usually where I start. And the second is using the screen reader to have the voice from the operating system read out what is on screen. If those two things already work, you’re making very, very much, well, a lot of progress. And then after that, I would go sit down with the team and ask them what they think about how we could extend this. And I would probably steer to colour blind people so we could change the contrast in the app itself.
There’s also an option that the operating system would do this. And then I would try and set this up and give them the results. Like, this is what your app looks like when the contrast is set to this or that. Does the designer agree? Does it have any implications for, uh, the logos that we use?
Are we using logos from different companies that they don’t want us to change the colours, but is it still, readable for other people? That’s what I always start and from there on, yeah, consult with the team or get user research on the people that are using your app.
How many people actually have this problem? And there are a lot, then you could always tell upper management, like if we fix this, there’s a lot of people that can use our app more and better, which in the end will give us better reviews because we thought about this and probably if you sell something through the app, more revenue, because people can actually use it now, so they can buy something through your service.
That’s a way to convince people on a tight budget, like in the end, it will actually gain you money.
Marion: And even if you don’t have the data we saw earlier that about 15% of the world’s population experiences, some sort of disability. So you can probably assume that about this percentage of your consumers would be happy about some sort of adaptation.
So how do we make apps and websites accessible? Maybe Martin, you can help us answer this question.
Martin: Yes, certainly. Thank you. I think a good place to start is who are we designing for? And the answer will typically be everybody. So we need to bear in mind that according to which place you look, you find that perhaps 15 to 20% of the world’s population experienced some form of disability, which is about a billion people.
So if you’re in marketing for instance, you might say to yourself, gosh, um, I don’t want to exclude a billion people. I better include them, but what we are actually talking about. Vision impairment is one thing, for example, somebody might not be able to see quite as well as somebody else. What does that mean? Does it mean that somebody is actually registered blind? No, it’s not necessarily that. For instance, I wear bifocals, so I have to move my head around to see things. And when I do that had the screen blurs and the copy blurs, text blurs colours, run into each other. It’s a bit of a mess, really. So vision impairment can be all shades of can’t quite see very well to not being able to see at all. I’ll come back to what that means in practice in a minute. Hearing impairments, there might be, something going on on the website that needs you to listen to it. Well, okay. It’s the person you’re playing that sound to able to listen to it.
Do they have impediments of their own, or is the environment, and they’re in an impediment? For example, if you’re trying to listen to somebody, giving a speech at an internet cafe on an app, without a pair of headphones, there’s going to be interference all around you.
An example of vision impairment is your screen is covered in gunk. Uh, you’re looking at a mobile phone and it’s covered in water cause you’re outside. You can’t see the screen properly. Another vision impairment is you are unable to differentiate certain colours. Red and blue is quite, red and green I’m sorry, is quite a common one. All sorts of things going on to impair your vision.
Physical disability is another aspect to take into account. This means you might not have full motor control. So, you may not get to use a mouse. Well, you may not be able to use a mouse on the desktop, but you may not be able to use a mouse because you’re using a phone. So the mouse doesn’t work at all, or you may have gloves on so that your fine motor control is lost.
You can’t point very accurately. Other conditions you might experience in normal life, whether or not you have mental health conditions, is that there could be something that just doesn’t work for you. So, some people are easily distracted. I know for instance, if I go shopping for clothes in a shop with TVs in every corner, I will look at the TVs and it will not look at the clothes.
I’ve learned that over time, I cannot stop looking at the TVs. So I ended up buying no clothes in those shops because I’m so distracted. We also have, intellectual disability that, um, you know, some people get it, some people don’t, obviously that’s a very crude definition, but something that’s obvious to me on the screen may not be obvious at all to somebody else.
So having common standards is very useful for that. So for example, a lot of companies will put their logo, top left. Navigation will be at the top right, in an e-commerce world, it might be the basket. These are common standards. You can put them somewhere else, but when you do that, you’ll find that other people don’t find them.
So those are a number of aspects. To take into account when testing it’s called accessibility testing, but I already think it’s testing for everybody. Not everybody is going to be able to experience the website you’re working on, on a mobile phone, your app, you’re working on imperfect conditions that need to be taken into account.
If you want your users to experience the site in a way you desire. And if you want them to get the point of your website, if there’s a message or we’re trying to get across, or there’s something you’re trying to sell or whatever it is, you need to make sure that the majority of people can get to what you need them to get to, the majority of times. And saying that, oh well, a certain segment of the market doesn’t matter, or people who can’t do that, well, you know, that’s, uh, let’s just leave them out in the cold. I don’t think that’s acceptable.
Marion: Definitely not. In this perspective, how would you go about creating products that can be used by everybody?
Roel: I think that it also starts with the design, to make that inclusive, because it’s a design methodology that enables and draws out a full range of human diversity.
And Martin already said, like, some people have maybe a impaired vision or are completely blind or on the other hand, people that I don’t know, lost an arm, so they can only use a one arm to control a mouse. And that might not be the dominant hand. And on the other hand, there’s also people that might have broken their arm. So they’re temporarily not able to use that mouse. It’s not always that you would make an app accessible to like only blind people, but maybe to people that have a little lesser vision or to people that had an operation done on their eye or had them lasered. So their vision will be blurry for the upcoming weeks.
So there’s a little bit of diversity in that. And the way that we found this or that I found this is the first time was for Tele2, where they made a new app and the old app was just pushed out of the store. We pushed into the new one, and then we got some customers, on Twitter actually, there is an organization in the Netherlands, especially made for well people with vision disabilities and they tweeted to Tele2 like, “your app does not support any options for the visually impaired people. You can not make the phones any larger. And, an iPhone cannot read the screen.” And that’s when we started testing though that the first time, and when I tested that the first time manually, it was quite, uh, quite a shocker actually, because they were right. None of it was in place that the things that the, what was it, Siri read out to the user was completely not what was in the screen and because it made such a fuss on the social media at that time, our team, our product owner decided that it was supposed to be a priority from there on out. So we had like two or three sprints where we solely worked on the voiceover on iOS.
Which I have to say Apple does very, very well. They have these labels called “accessibility labels”, which a developer can add to any element in the app. And it reads out where ever you put the accessibility label. So it was actually a very easily done. And on Android, on the other hand, you have way more segmentation in brands, but also in the type of screen reader that you can use.
So there’s a lot of third parties. That took us way longer to actually figure out. But in the end we did. And, we sent people the notification, to customers, that experienced difficulties. Like we updated our app. Are you willing to change your review of the app? And they actually did. So, yeah, it became obvious to the company to that the reviews rose in like the, the amount of stars that we got, like this was a very good investment to make because now everybody, even more people can actually use the app, which is on a commercial level.
Also very interesting because you just broaden the group of people that you can service with your app. So potentially more money to be made, and I think that’s what actually drew them over the line from “what we got to work on this, because we are missing out on, customer service, but also on revenue from our app.”
Marion: Roel, would you say that before this incident on social media, accessibility was something that was considered important or did it take the backseat.
Roel: Well, I came into this team making the new app, so I have no experience with the app that they had before, but apparently that already had a lot of accessibility labels in place.
So that worked fine and now it was missing, so people were like, “Hey, you made a new app, but it doesn’t feel like it’s an improvement over the former one for me as a user with a visual impairment.” So, yeah.
Martin: Also, the aspect of accessibility running into usability. The subject, so for instance, how many times have you visited a website to find that you’re looking at a light gray text on a slightly darker gray background. That’s almost unreadable. How many times have you listened to a video where there’s a part, which is important, it might contain a phone number or something of that nature. You don’t hear it the first time, so you have to try and rewind it and here again still can’t hear it. Try it again? How many times have you visited websites and you’re scrolling down and maybe a pop-over, pop-under, or combination thereof takes over the screen? And you can’t find the close button because it’s not top left.
They’ve moved here bottom right. Or something. So you start looking at an advert for instance, and you can’t go any further. How many times have you tried to fill in a web form? You come to the end and press “okay” and it’s not done anything. And despite your best efforts, you can’t find where the error is because the error flagging is so weak.
These are all taken into account by very simple accessibility standards that lead into the usability of the site for everybody. And again, I really believe that these issues should be taken into account from the beginning. And as Roel says, you start with design.
Roel: That’s where people get excluded by the design.
And at Tele2 this was obvious because the exclusion happened when like the designers tried to solve the problem using their own biases. So from their experience, it was like, “yeah, this is what these people want. This is what we think works best for these kinds of people for our target group.” But that was just from their own point of view.
And when we actually got into contact with the people that were in this case, like visually impaired, it’s like, oh, we never actually thought about it, in that sense. So we might have to change our design around the other way. I was looking up a disability because. Uh, accessibility. Usually, the first thing is, yeah, we’re going to do make it accessible because people with a disability needs to be able to use this as well.
And we have like a part of the 1980s when the World Health Organization is that, uh, the disability seen as a personal attribute, but in the context of health experience, a disability is a restriction or a lack of ability, resulting from an impairment to perform an activity in a manner or within the range considered normal for human beings.
But now, these days, disability is seen as a context dependent. So disability is not just a health problem. It’s a complex phenomenon reflecting the interaction between features of a person’s body and the features of the society in which he or she lives. So like in what is it almost 40 years? The [definition] of disability has been developed the way that we look at it or the World Health Organization looks at it has changed as well.
Martin: I think the strong connection between accessibility and disability is actually false these days. I think context, as Roel said, is very much more important and it’s more recognized. So this morning when I got to work, I was wearing a COVID mask and my glasses steamed up. And I was trying to see through that, to my phone, which was, had a few raindrops on it to use the door key app.
So first of all, I had to find it. First of all, I had to turn my phone on and I was wearing gloves. So I couldn’t take the pin code. And then it didn’t recognize my eye cause in the class had a steamed up. So then I took my glasses off.
Now I’m, short-sighted looking at the phone, which is covered in water, trying to find the app.
And I found the app. It started, but the text was too small for me to work out exactly what I was doing. So by the time I got it to work, I was, I was quite upset. And that’s just a small example of these days your life revolves around a phone. It’s small. You can’t see it that well in bright sunshine, can’t see it at certain angles wearing sunglasses, and if it’s damp and so on and so forth, all sorts of things going on, a lot of the issues you face can be eased by taking into account accessibility at the beginning.
Roel: And having design check those situations out first and then try to design around it, instead of just creating an app and then have us testers go at it. Like, would this also work if I was holding a baby or what is also work if I had an eye patch? I think it works best if designers think about those kinds of situations and, well for example, people that are colour blind, at the project that I’m working on right now, is we had a couple of these things with the voiceover, which didn’t work.
So I gave a little presentation about accessibility. Like, how about we just make a switch in our app that changes the contrast around or the colors around for people that are color blind. And there’s not just one type of colourblindness. I think there are three major ones that people have, so you have to have three switches, but this, in hindsight for the designers, was like, “oh, so we now have to make three different color designs that actually look good, but also work for these people.”
That’s going to take a lot of work, but yeah, if you’ve thought about that before we wouldn’t have that. And of course, there’s a lot of things in phones right now where you can just change it and all the apps change. But, brands, for example, like big banks, or anything, are like, yeah, but now, the operating system changes our colours and we have this set of rules that say that you cannot change the colour of my logo.
But then the operating system itself does that. So when this came to conversation, yeah, well, we can take matter into our own hands and just change it the way that we like, and it still works, but yeah, that’s going to be a lot of extra work and, also of course, needs to get tested. I wonder how they did these kind of things back in the day.
Martin: That’s a good question. In the beginning, we would do it manually following, uh, the W. Oh, I get this wrong. The WCAG guidelines, level A, level AA, and so on. And once we’d done that for a few projects, I was in a development team at the time we found that it became second nature. So for instance, don’t put text over a photograph or an image that’s got a lot of colors in it, put it against a block of color, so it can be more easily read. That’s a simple one. Uh, another simple one is we’re going to use the tab key. The input fields should rotate in a logical order, typically clockwise. That’s another easy one. Things like form data checking and error handling.
So that if you put a phone number in and it’s got characters which are not recognize it in the phone as phone numbers, then to put up an error message against that field that says, “I’m sorry, we’ve got a problem with your phone number, we’re expecting this format” that became second nature. Before we had that discipline, what we would do is we would throw an error at the bottom of the form.
“Error” or “wrong phone number.” We wouldn’t indicate the field. And we wouldn’t tell you what was wrong with the phone number or what we’re expecting. So we knew what we wanted, but we weren’t telling the user that, and we accepted very quickly that that was not best practice. So a lot of the guidelines we use manually were built into house standards very quickly because they made a lot of sense.
We were also using voice readers, like jaws at a time. But it was certain levels that our clients were prepared to go to. So our house standard was somewhere between WCAG level A and level AA. And I would argue that the website’s reproduced using those standards were more usable for everybody.
And then the websites we’ve been producing before, they were just as creative, they were just as exciting, and they were just as dynamic, but they were more usable. And the secret sauce was accessibility standards that we were using behind the scenes, which was the WCAG standards, which is still there now.
America has Section 508. Very similar to the W3C standards. The EU Directive 2102 is out there now. If I’m correct, then that directive requires standards to be applied to European websites from now or from the summer anyway. So we should all be doing it. I’m not quite sure why we’re not.
I’m not quite sure why some clients don’t take this route from the very beginning.
Roel: I think I have an idea.
Roel: Money and time.
Roel: That was at least for my experience when accessibility came up, it’s like the upper management goes like, “All right, this is probably important, but how much time is it going to cost? How much is it going to slow down the next feature that we actually want to, to bring to our service?” And if that’s too long or it’s going to cost them too much? Yeah. Time is money. And that, in that sense, always it’s like, yeah, well maybe we’ll brush over this for now. We’ll maybe adapt to it later.
Marion: And then later becomes, never.
Roel: Yeah… there’s this Dutch saying, “van uitstel komt afstel” which means that if you postpone it, you will, on the long run, you’re just not going to do it. You’re going to cancel it.
Martin: Yeah. So I think there’s a lot wrong with that approach, it is literally shortsighted. As we’ve described earlier, management taking those decisions are excluding around 20% of their target markets.
Why would they do that?
Roel: Well, yes, this is of course, one of the things that I think this is the shortsighted version because, the points of exclusion, they will help generate new ideas for and inclusive design, which broadens the group of people that actually can use your service. So on the longer run, it actually might help you get more people using your service. Which will automatically or will probably create more revenue or income. It’s just an investment that you have to make.
Martin: There’s a there’s a story. At the beginning, when the web took off, supermarkets based in the United Kingdom, looked to the web to expand their sales and without naming names, one supermarket designed [a website] from the ground up to be accessible. And the other major supermarkets did not. They didn’t think of it. They didn’t think it was necessary. What happened was the sites that were designed by the supermarket that took accessibility into account from the first place was easier to use. He was also the only site that was usable for anybody with a disability, which, as we said, is 15 to 20% of the population.
The results of all this, was that the supermarket that took the accessibility guidelines into account in the first place? Absolutely cleaned up, dominated the supermarket, online e-commerce market because the other sites, but literally not usable.
Marion: Thank you, Martin. That’s a great example to use if you are faced with colleagues who don’t see the value in taking accessibility standards into account, or they think it’s too time-consuming or too expensive. If you’re one step further, and as a development team, you want to, you want to make more inclusive apps and websites. How do you get started?
Martin: You Google the subject, uh, research. There’s a number of excellent checklists available, and it’s surprising how easy a lot of the guidelines are to implement.
If you just accept that by doing it, you’re going to make your deliverable more accessible to more people. One way of looking at it is that by following the guidelines, you are ensuring the largest number of people can read and operate what you’re delivering, regardless of their ability or circumstances.
And that must be a good thing. The guidelines been talking about how well established, there are testable success criteria. There are lists of techniques you can use. So onboarding this for the first time. Uh, it’s eye opening. And once you’ve done it, you wonder why you didn’t do it earlier. And I can assure you, you will keep going with it because it just feels, uh, the right thing to do.
And the work you’re producing is available to more people, more easily. So hey, do that. Lastly, from my point of view, the guidelines, by using the guidelines, it also makes you, you as a human being, think about other people, their circumstances, and their abilities. And that’s a good thing, too.
Roel: I was educated to be a designer. One of the weird things, when I look back on it, it’s like we never actually, as designers learned from our school to be inclusive in our design, we just, we were taught to target one group of people. That’s who it should work for nobody else around it matters anymore.
So if a blind person could not use our app, we would just go, “yeah, well, it’s not made for blind people. So, yeah. Sorry,” which is in practice, a really weird thing and then becoming a manual tester. When I started out, one of the things that I tried to do was like break the app in like putting the fonts are really big, like, oh, well now it breaks. But uh, looking back, I was like, it, it’s a very important accessible testing start starting point, I think. Trying to break the app in that way made me think about, oh wait, but there’s people that cannot see. So, there’s two options here, we could just make the service in a way that they cannot actually make the font any bigger. So well that solves it. The bug is actually solved, but what it does is introduce a whole lot of exclusion to other people that have bad vision.
And so going on to that was like, oh, we also have people that cannot hear, so I very much experienced from hands-on and I’m thinking as a user, being a designer first, gave me a lot of experience with that.
And then when Martin came with the, with the rules that he posted like, oh, this is a, a very good set of well texts and rules. That I could just throw against the teams that I am working with. Like, here, I could try to explain why this is all important, but here, this is what we could do and why it is important. So I, I don’t necessarily have to do it, out of my own experience anymore.
So these guidelines were very, very helpful. I think that every, you know, every European country has its own set of rules accessibility and inclusiveness. Correct me if I’m wrong.
Martin: As far as I can see, the Netherlands guidelines are actually dependent on the worldwide web guidelines W3C. So those are the ones that are truly different I think.
Slightly different, I’m sorry. There’s section 508 USA, but they’re all, they’re all pulling in the same direction. So if you’re in any country you would go for the worldwide ones. I think.
Marion: We will post the links to the guidelines and other interesting resources on accessibility testing on our website with this podcast.
Now let’s wrap this up with one last question for Roel: what is the response when you introduce these accessibility guidelines for the first time in a team? Is it something that people know of or is it a bit of a surprise?
Roel: Yeah in practice. I always, well, you always get, ”this is not on our roadmap, sir. So I’m very sorry, but we don’t have the budget. We don’t have the people for it.”
So it’s like, yeah okay. I try to give them an example of their services, where I, then put the font to very big, or I use the voice over. And just have them listen to it or look at it like, this is what your service also does and it does not work correct. So just imagine you being a customer to your own service, how would you feel if this was what we would have made for you as a company and then is when people start frowning. It’s like, oh yeah, I didn’t actually look at it like that. Is this a big impact? Yeah, we should do something about it. But just telling somebody that you should make your app accessible for everyone usually ends up, well at least in my experience from being hands-on on the working floor like, yeah, yeah, yeah. We’ll talk about that later. Or, we don’t have the time for it.
Marion: Okay, so you have to present it a bit more in a how to make your customers happy perspective.
Roel: Yes, but once that ball start rolling and they’ve seen what we can do and then get or ask for positive reactions from the people that we actually made it for, it gives the team a good feeling about their product and themselves. And also, hey how do you say that more… self-assured about the quality. So, when they start on it, it usually contributes at like the, all the next levels of the product. Every next step, it’s like, oh wait, we need to put in the accessibility stuff from the get-go now so we already got that managed. And then when you keep working on it, like maintaining, it is a lot easier than introducing it for the first time.
Marion: So that’s maybe a good bridge to our closing. We can see accessibility testing is really good for everybody. Be it, the user in need of adaptations or the developers and testers who can feel good about their work.
Roel: Yeah, I think it’s your responsibility as a tester, especially a functional tester, to test it for everyone. So think about all the situational things that could happen: from somebody who has just had a kid, to somebody who has lost an arm, to somebody who has a cast around their arm. Introduce that from the very get-go and you don’t have to like push it, but at least make them aware. You’ve said it and you wrote it down. So eventually they will have to come to it.
Marion: Thank you Roel. Martin, do you have any closing remarks for us?
Martin: Well, thank you for the opportunity to talk about the subject. I think it is important. I think it has been for many years, the next big thing. And I think, I’m looking forward to being the next big thing. We should as an industry, be taking into account these standards from the very beginning. And I would urge anybody listening, who is not doing that to simply do a little research take an onboarding and start doing it. Let’s make the world a more accessible place.
Marion: That’s a great word to end on. Thank you very much Roel, Martin, for taking the time to discuss this with me.
Roel: Thank you for having us.
Martin: Thank you.
Marion: And many thanks to you who listened to our first podcast episode, you can find the links to additional resources on accessibility testing and inclusive design as well as sources on our website. Have a nice day.
Number of people experiencing disabilities
The World Bank. (2021). Disability Inclusion. https://www.worldbank.org. Retrieved 23 December 2021, from https://www.worldbank.org/en/topic/disability#1.
EU Directive 2102
EUROPEAN PARLIAMENT AND THE COUNCIL OF THE EUROPEAN UNION. (2021). EUR-Lex – 32016L2102 – EN – EUR-Lex. Eur-lex.europa.eu. Retrieved 23 December 2021, from https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.327.01.0001.01.ENG.
World wide web guidelines
(WAI), W. (2021). Web Content Accessibility Guidelines (WCAG) Overview. Web Accessibility Initiative (WAI). Retrieved 24 December 2021, from https://www.w3.org/WAI/standards-guidelines/wcag/.
GSA. (2021). Section508.gov. Section508.gov. Retrieved 24 December 2021, from https://www.section508.gov/.
Stichting drempelvrij.nl. (2021). Waarmerk Drempelvrij.nl voor digitaal toegankelijke websites. Waarmerk drempelvrij.nl. Retrieved 24 December 2021, from https://www.drempelvrij.nl.
Apple. (2021). Introduction – Accessibility – Human Interface Guidelines – Apple Developer. Developer.apple.com. Retrieved 24 December 2021, from https://developer.apple.com/design/human-interface-guidelines/accessibility/overview/introduction/.
Microsoft. (2021). Inclusive 101 Toolkit. Microsoft.com. Retrieved 24 December 2021, from https://www.microsoft.com/design/inclusive/.
Walk into Paradise by Carmen María and Edu Espinal