Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Welcome to Testing Experts with Opinions, an inspired testing podcast aimed
at creating conversations about trends, tools, and technology in the software testing space.
Morning, guys. Everyone well? Morning, Liam. Good morning, Andrew. Thank you.
It's been a while since we did the last one. It feels a bit wrong that we've
(00:20):
had to delay it so long, but it's good to have all of you back for a conversation.
So what we want to talk about
today is accessibility testing and and maybe stretch
it to usability testing as well i feel
it's it's a testing type that's that's often overlooked not necessarily considered
but it's becoming more and more important with regulations in in the uk and
(00:45):
us specifically obviously regulations elsewhere in the world as well but those
are are probably the two main ones.
So does anyone want to just open with maybe just giving us a brief explanation
of what accessibility testing actually is?
Yeah, so I'll take that one. So accessibility testing kind of comes from that
legal framework originally.
(01:06):
So there's two acts in America and the UK.
So there's the ADA Section 508 and the WCAG guidelines, which usually apply to Europe.
And that's about making sure that your website or software service or application
is accessible or usable for people with disabilities or specific needs.
So that could be something like colorblindness, blandness, or hard of hearing,
(01:29):
things of that nature, and how it differs to usability.
Usability is making sure that the user is having a pleasant experience with
the application, and that's more about catering to everybody.
So there are some subtle differences between the two of that.
I think it pretty summarizes it reasonably well.
Perfect. And like you mentioned, the goal is to create digital experiences that
(01:51):
are inclusive and provide equal access to information and functionality basically
to everyone, regardless of your abilities.
So just jumping straight into it, are there specific sites which are more important
to have accessibility, a really good standard, high standard of accessibility compared to others?
(02:11):
So, i.e., can certain companies get away with not having to do accessibility
testing, whereas with others, it's really important.
Yeah, it's a good point. So there's different ratings within the WCAG guidelines.
So for the UK, it can be rated depending on how compliant you are with the guidelines.
I think to kind of answer that question, I would go with it would be dependent on your user base.
(02:36):
So if you're looking at something that's maybe internally facing to the company
and you'd know that there's nobody with accessibility needs in the company because
it's quite small and you know everybody, it's probably less of importance.
But if you've got a public-facing service, some of the big applications,
So you look at anything from Google, anything from Microsoft,
it will need to be accessibility compliant because the amount of the volume
of traffic and the volume of users that will be engaging with that platform
(02:57):
will highlight a lack of accessibility provision within it.
And what is interesting there is that from a legal perspective,
I think, Steve, that is correct.
But from a business perspective, it's also a little bit different.
So if your user base, and I'm thinking of an example of one of our clients.
And so their user base are people 60, 65 plus, and they don't necessarily have disabilities.
(03:24):
But for them, technology, and I'm generalizing, technology is a little bit different.
It's a little bit harder to see the colors on the website.
From an accessibility and usability perspective, things are different for,
again, generalizing 65, 70-year-old people than 20-year-old people.
So their website that they go to, and it's not a big base like Google,
(03:46):
but that's that organization's whole client base.
So if you look at that organization, 80% of their client base will have a different
need from the website, the accessibility of that site, how big the font is,
because can they see without their glasses, where the buttons are, text to speech.
So even if it's not a legal requirement for that organization,
and then it should be, we'll talk about that a little bit later.
(04:08):
But from just from can my user base use my
website it's also a big consideration yeah it's
a really good point and i think if you look at something that like
for example should be applied to all applications or websites
would be something like seizure safe profiles so
you can't have like flashing juxtaposition text and
colors on a screen part of your service because it
(04:30):
could induce someone with epilepsy so there's a there's an element of of the
severity of the risk of the impact of not doing the change the font being difficult
to read for someone who's elderly i can maybe get away with as a business but
i can't get away with causing someone to have a seizure and you know legal and
legal and ethical moral ramifications of doing that.
Yeah, it's an interesting one because someone mentioned to me the other day,
(04:52):
and both of you touched on it, the user base is so important to consider.
So if you think about, I'm just going to use an example, let's say an investment
company or a wealth business, and you look at their user base,
it's probably safe to assume that people that visit their website are slightly older.
It's probably people that have a bit more, I want to say, disposable income
(05:16):
to invest. invest and obviously there you consider that potentially their eyes
are slightly worse, maybe other aspects.
So maybe in that situation becomes a lot more important, not that it's less
important on others, but it is that balance between how much investment you
want to make, how important it is.
(05:36):
Obviously there are certain sites and industries which which are heavily regulated,
where it's a legal regulation, more expectation for you to actually certify to certain levels.
But then you have those other ones where it's not necessarily regulatory.
(05:56):
It's not getting forced on you, but you realize it's actually the right thing to do.
And it's important, given who visits my website, to be able to provide the best experience possible.
We touched, you touched on a couple of examples there, flashing images and that type of thing.
What are the, I almost want to say, what are the main factors that one needs
(06:19):
to try and address when you're looking at accessibility?
And maybe before anyone answers, if someone can just explain the three levels
of WCAG as well, A, AA and AAA, you don't have to go through every one,
but just at a high level, what they mean and why there are three different levels as well.
Yes so i would say is around the dvcg it's
(06:41):
quite difficult to they do a reasonably good
job so if you go to their website and you look at the standards which
are constantly updated as well so that's something that this isn't a fixed point
as well so something to maybe point out is that for businesses isn't a
case of we're now compliant and that's that's great they're constantly evolving
the the guidelines and improving them and that's to keep pace with technological
changes and better understanding of people's specific user accessibility needs
(07:05):
and how it's important to them. The tiering system is kind of around.
Like a gold standard. So for, like, say, something like a public-facing website,
you would want to be at level three. You'd want to be the highest level of compliance.
If you're a small startup company and you're selling an app on the App Store
to 12,000 people, 10,000 people, you could probably get away with a one or one star.
(07:29):
And the differences are kind of nuanced in the specific elements.
So let's say color contrast is an example that if you're three star,
I'm going to put this off my head, if you're three-star everything
on your website every single page needs to have a color contrast
ratio that is say of a specific number
and then for a one it might be 75 percent
(07:50):
of the material needs to be of the same level of compliance so it's how thorough
a lot of the times you are in terms of ensuring the standards and then also
higher thresholds of tolerant higher thresholds and what that looks like as
well if that makes any sense yeah and so i think you said it steve So the basics
should still be in place for all three levels.
And the basics are things like, can I use my keyboard when I can't use a mouse?
(08:15):
Can I see the screen? And are text readers able to read what is on the screen back to me?
So those basics are still in place for all three levels, but it's the thoroughness,
as you said, Steve, and some nuances around it.
But at a basic level, can I use my keyboard?
And can some screen reader read what is on the screen to me so I can actually
understand what is going on on the screen.
(08:38):
Stefan, where does accessibility testing fit in? In terms of the usability testing?
Yeah, and I think also in terms of when you would do it, when you would consider
it, is it deemed to be part of manual testing?
Is it deemed to be part of, I don't know, non-functional testing?
Oh, in that space, definitely.
(09:02):
I think it's it's more on the non-functional side where it's
you know it's more of a non-functional side i think but
although inherently it is something that you also possibly test as part of functional
testing as well i think a lot of those things you would pick up yeah for example
if there's a not an x button all those buttons are not the same you would you
would pick it up as a part of your functional testing but if you look at icgb
(09:25):
or the normal categorization i would
say mostly falls under the non-functional testing
although there are overlaps with functional testing as well it is
also typically to add on to that it's also typically something
people do ad hoc at the end
of a project and and we've seen now that the
trend especially because companies are being forced to
(09:45):
do that that accessibility testing becomes part of
the development process and and moving it shifting it
more and more and more left from a design perspective because that's where
accessibility really starts it starts with design if you
can catch those things accessibility issues in the design phase that
makes it a lot lot easier to catch and fix and build that into the process but
(10:06):
we've also seen test analysts being exposed to accessibility testing looking
introducing accessibility testing and requirement analysis so if i'm a functional
tester manual functional test and i'm sitting in a requirements analysis
session and there's a design and I start asking questions about,
even if I don't know a lot about accessibility.
(10:27):
Do you think this ratio is right are there accessibility things we
need to consider as part of the requirements for the
story or the for the story that we're taking into
the sprint we're seeing the testers slowly and slowly moving and shifting left
with accessibility testing as well unfortunately there's still something because
of the history of it where companies decide oh we are live or we're about to
(10:48):
go live let's look at accessibility testing which is a typical example example, but it's too late.
And we're advocating that we start moving it left and start having that conversation
at least earlier in the life cycle.
Yeah. It's like accessibility is like quality. You can't test quality into a
product. You have to build it in from the start.
And to pick up on your point on accessibility on a previous client.
(11:11):
I would get non-functional requirements or user stories that say things like
application must be accessible or accessibility is not applicable or system
must cater for for people with accessibility needs,
whereas I pointed out, what specific user needs are you thinking that we need to cater for?
Have you identified a user group in the company that needs, for example,
(11:33):
contrast readers or they use a screen reader on a regular basis?
Because that's something we can't just ad hoc find out that needs to be built
in from the initial design.
And that's where we write test analysts and testers and need to challenge those
kinds of requirements and feedback to the business that I can't test that for you.
That's something that we need to really build out in the design. time a lot
of the time people only think about performance and security but this
(11:55):
is in a way a very low end fruit kind of requirement that
if you just explicitly think about it and challenge it
in the in the requirements up front it's something that can without too much
effort really be baked into it from the start like you guys said so and what
is interesting there stefan is that with performance it's always a conversation
should we do performance testing when do we do performance testing what is the
(12:15):
business getting out of it and and we've we've we've done a lot of
exercise in improving the value of performance testing, for example.
But accessibility testing, if you look at a business and things we've said earlier,
it directly increases your user base and people who are able to engage with your business.
So from a business perspective, it should be quite an easy sell to say.
(12:37):
Start doing this can use our our website or
our business or engage with our business and our current user base won't
be frustrated and leave i think from a business perspective it's
quite a easy business case to make and yeah
and you mentioned the other day when we had a similar discussion companies might
think is it really worth it how many use how will it really will it really increase
(12:58):
my user base but you mentioned something interesting to say sometimes there's
a temporary disability like i forgot my glasses at home and that's almost a
very common kind of scenario and something silly like that somebody trying to
view websites and not being able to.
View whatever they want to view could you know could actually
have a big impact and i think there are certain cases like that that actually
(13:19):
you know have a bigger impact than you would anticipate so you know definitely
easy use case to make the business and and luckily my parents aren't listening
to that but they are older and if they want to do banking for example they phone us and
say, I can't interact with the banking side,
please transfer some money, or I can't sign up to this policy,
(13:41):
I need my policy documentation,
it's tax season, please go get it for me, because I don't understand the system,
I don't know where to get that from.
And luckily, we are still there to do it for them. But I imagine people in similar
situations, they don't have anyone to phone, and they just don't interact with
that website, they just don't get the policy, or they have to find a broker
(14:02):
or something to do it for them.
But But the point is that they are being frustrated and they're not going to
interact with your business because of the site not being accessible to them.
And they don't have any disabilities, but it's just that accessibility part of it.
And the point I'm trying to make is that accessibility is not only for people
with impairments or disabilities,
but it's also, as Leona said, look at your user base and see how they would
(14:24):
interact and the profile of
them and how easy it is for them to interact with technology or the site.
Yeah and i think another business benefit is i
worked i worked with a ux designer at my null client and
something he pointed out to me is if you design your website
or application to be accessible and
(14:44):
meet the guidelines you will accidentally make it
usable a system application that is
accessible has good contrast spacing ratios layout
and structure to meet those accessibility guidelines is an aesthetically pleasing
website they're nice to look at they're nice to navigate they're nice to follow
so you're killing two birds with one stone a lot of the time well there's certainly
(15:05):
a lot of crossover between the two so it's also another advantage that you'll
probably get a better designed website out the back of it as well,
Okay, great. So you guys have done an amazing job at selling accessibility testing.
And now there are people out there that's never done it before.
Where do they get started? How do you actually go about doing the testing?
Is it purely a manual task or are there automated tools that you can use as well?
(15:30):
But maybe before that, just as a starting point, someone that's never done accessibility
testing, a company that's maybe never looked into accessibility testing,
what are some of the starting points for those folks?
What i what i would say is don't go straight into reading
the guidelines because it's gonna it's
gonna this is very complicated they're quite there's a
(15:53):
lot of detail in there i'll give you a really simple use case example which
i think anyone can use most microsoft products have accessibility testing tool
sets built into those so if i'm building a proper presentation or a word document
at the bottom of that toolbar that microsoft will tell you there's an accessibility.
Issue there for you to investigate if you just double
(16:14):
click on that link it will take you to
a toolbar and it'll say for example you've used a merged table
on this header here which if i'm using a screen reader will
create a problem for that user or the contrast
between the title and the background is it's
off it's quite hard to read and that will start to get
your head into oh these are the kinds of things that we should spot and kind of
(16:36):
notice that's a really simple way of of doing it another tool
i would use would be something like a color contrast checker which are free
online and that's just a way of checking that the ratio that's
being used on the site is appropriate and there's also like online tools
you can use these are all manual things you can do pretty quickly
without having a need to build up a huge skill set in terms of doing them it's
just it's you just need to be having awareness of the issues first and the tools
(16:59):
are available for you to use yeah and and similarly to the microsoft things
that you've mentioned steve if If you go to your website in a browser and you
go to the development tools,
they have accessibility tool built into that already.
So for Chrome, for example, Google Lighthouse will give you accessibility scores and ratings.
The same with Edge. So it's already built in. If you are an organization saying,
(17:22):
oh, it would be interesting to see where I stand, that's a very good start.
You go F12, you go to Google Lighthouse, you say I want accessibility report
and we'll spit out a fairly detailed accessibility report already about your
website. and what is going on on the page it sees.
There are fancier tools like Axe and Wave that can do that.
But I think as a start, if you do the native checks that's in the browser,
(17:46):
that will give you a great start. Just to understand what you are seeing.
It also, as Steve has said, you don't have to go read the manual to do that.
It will spit out a couple of fairly obvious things talking about contrast,
talking about screen readers, talking about usability and the keyboard usage
of that. and you can already start.
With that report and taking that to your design team or your engineering world
(18:08):
and saying we are seeing this what does it mean so that's
already a really really good start from automation perspective there
are tools that will help you with that but it is still i think it's still a
very manual effort as it should be it's a report it's not on anything so it's
a report that you get you have to rectify and test the game a lot of people
have started building that into the automation frameworks they they kind of
(18:31):
call it the missing tip of the automation pyramid from a visual perspective.
So if you have a baseline to say, our baseline is already accessible,
let's just compare every release against that baseline to make sure that it still looks the same.
That's already a very good start from a regression testing perspective to say,
are the elements still looking as we've designed them according to our accessibility
(18:52):
guidelines that were given to the design team?
So you can start building that in your process, but as a first glance,
use the browser and the native tools that are in there.
And if you're looking like say more of a uat focus
to it reach out to the to the company that
you're working in or the client you're working in do you have anyone in
the company of the client that has accessibility needs and get
(19:13):
them to just use the site with you or use the application with you you can also
reach out to i know quite a lot of charities in the uk will actually offer people
up as volunteers to test your website that may be short-sighted or registered
bland and then they will actually give you a feedback report on what their experiences
were like that's really useful to get actual hands-on user experience with the site as well.
And I think that's invaluable, Steve. If you look at accessibility and impairments.
(19:38):
People with those impairments or disabilities are the best users to give you
feedback on a thing. A guide is a good thing, and you think you know.
I'm taking myself as an example with a physical disability that if I go to a
place where they designed a RAM, for example, and I did it the other day,
the RAM was on the side and with the incline, I don't know, 60 degrees.
(20:00):
I'm over-exaggerating.
But no one in a wheelchair will ever get out there.
But they've met the requirements. So feedback from people who need to use the
site and have the disability so on payment will really give you the feedback that you need.
And you don't always have access to them, Steve, but it's a really good idea
to get that real user feedback before you just design.
(20:22):
And it's not something that I was thinking. I think a lot of people might maybe
just do it the first time they deploy a website and then almost forget about it.
It should be something that's regularly tested, right? It's not something that's
a once-off and then you forget about it and you hope it doesn't regress with time, right?
So it's like you say, it's a mindset and it should be regularly checked.
(20:44):
Yeah, I'd add it to your regression like anything else. is if
i've made a ui change to the website i'm
going to regression test it to make sure that i haven't broken
some of the previous accessibility provisions i've made a common
one for that would be like if you're using keyboards to navigate the
website and you've moved the object orientation around and
you've added a new feature and now the screen reader is kind of doing this down
(21:06):
the screen instead of going line by line by line so for someone trying
to use a screen reader it makes it very difficult or doesn't make any sense
or adding videos to your website and putting
them as autoplay straight away so the first thing the person hears is just a
blab of video audio and they don't understand what's going on you should never
you should never have autoplay video that's another good example of changes
that people often put in and don't think about the ramifications that would
(21:28):
happen when you do that yeah and i think i was just going to add to that i think it's,
to change the tab order on a website is so easy to do but you don't necessarily
understand the impact that's going to have on a person who who needs to to actually
use that that feature and.
(21:48):
I'm probably putting a target on my back here with developers,
but it feels like it's easy to miss that, to actually consider the tab order,
especially when you're adding new elements, et cetera.
And that's why it's so important to do ongoing accessibility testing because
you could have tested that tab order two months ago. It was all working fine.
(22:10):
But since then, there's been six more releases or eight more releases,
and somewhere there, something has gone wrong.
So it's almost like if you don't do it on a regular basis, it's almost like
creating technical debt as
you're going along and you're getting less and less and less accessible.
So it's really important for companies where it's important for them to be very
(22:31):
accessible to actually incorporate it as part of their testing and their SDLC.
See and that leon is something that we said
earlier is a heavy manual component to it in terms of manual testing but that
specifically on the tabbing is something definitely that can be automated so
i think we need to think about what which components sort of lean towards automation
(22:52):
which ones are manual because there are opportunities for automation in this space.
Yeah and then the other thing is and i think someone alluded to it so i'll just reiterate iterate.
We often think about our customers and our customer base, et cetera,
but your employees are your customers as well to some degree.
So if you have internal systems, it's almost as important to do accessibility
(23:12):
testing on those systems to make sure that someone mentioned forgetting my glasses
or maybe my mouse stopped working and there's no other mouse in the company
or whatever that situation is.
It's equally important, but I'm also being pragmatic here.
I I know companies aren't necessarily going to invest in getting their internal systems accessible,
(23:35):
but I think if it's just at the forefront of people's minds when they do testing
and they have some time and maybe if there's internal development on systems,
it's very important to consider as well.
Okay, perfect. Thank you, James.
Very enlightening, very interesting. Thanks for tuning in.
Until next time, when we... I just want to mention, if you do have anything
(24:00):
interesting you want us to discuss, I know I ask every week,
but no one has given us any topics yet.
So I'm still hoping that at some point someone will actually chip in to say,
we really want you to talk about this.
So if there's anything that you want us to discuss or anything you think might
be interesting to hear about, please let us know.
But thank you very much. And until next time, we'll see you soon.
(24:22):
Thank you. This has been an episode of Testing Experts with Opinions,
an inspired testing podcast.
Find us on LinkedIn, Twitter, Facebook, Instagram, YouTube, and TikTok,
where we're driving conversations.