Full Transcript

Adam Churchill: Hello, everyone, welcome to another edition of the SpoolCast.

Recently, Derek Featherstone presented a virtual seminar called Accessibility as a Design Tool. Now, this seminar, along with 100 others that teach the tools and techniques you need to create great design is part of the UIE user experience training library.

In the seminar, Derek showed us how beautiful, inexpensive and delightful user experience driven accessibility can be when it's actually addressed early.

Hey, Derek, thanks for coming back to talk more about accessibility.

Derek Featherstone: Hey, Adam, thanks for having me.

Adam: For those that weren't with us today at the seminar, can you tell us a bit about what you talked about?

Derek: Sure. The whole premise behind the virtual seminar is that we want to use accessibility as a design tool. It's not just something that we need to comply with. Certainly, there is a level of compliance that's required for many organizations in terms of accessibility.

But we wanted to take a look at it as an opportunity to make it something more than just that and turn it into something where it's actually an integral part of the design process.

Part of the reason for this is that we worked on quite a few projects where we've been called in to do accessibility work and to do usability work. The two are so very similar. In a lot of ways, when we talk about our accessibility work, we talk about it as straight up user experience work, but with very specific populations of people.

One of the things that we've found over time in working on these projects is that we quite often find that the usability problems that people without disabilities encounter are very much the same as the usability problems that people with disabilities encounter. It's just that people with disabilities, those problems have a much more significant impact on people with disabilities, almost like the disability acts as an amplifier for usability issues.

Something that is a usability problem that might take yourself or myself two seconds to recover from a little problem, that actually might be a show stopper for somebody with a disability, just because of the way the interface is designed or coded.

One of the things that we found through all of that work is that there are a lot of scenarios where we really want to focus on accessibility as creating really wonderful user experiences for people that happen to have disabilities.

What we've started to do in a lot of the training that I've done is I'm showing examples of fixes and new designs that better take into account accessibility. I've had lots of designers say to me, "That's great that you've made that change for accessibility, but it looks to me like that's just a better design, period."

When that happened once or twice, it was a coincidence. But when it started to happen on almost every single training workshop that I was doing, when there was somebody saying that almost every time, I knew that there was something more to this. That if we use accessibility as a design tool to help make our designs better, they're actually going to, in many ways, make the design better for everyone.

In the virtual seminar, we talked about that premise and went through a number of different examples and ways to improve the overall design process by making sure that accessibility was taken into account at a lot of different phases, whether we're talking right at the initial project conception stage and project definition, right through to user research and design iteration, and then development and implementation.

Even post-launch, how do we integrate people with disabilities into all those different phases of a design process to make sure that their needs are represented, but also to make sure that the design can be improved for everyone?

Adam: The gist of the seminar is, let's think about accessibility earlier in the process. What thoughts or tips would you offer up to a design team that buys into this idea, but they've got this existing process?

Derek: You know, there are a few key areas that we tend to look at. When we're working on a project with an existing team and they've got a specific project plan, or a process that they use, what we try to do is look at projecting specific phases of work that we normally do and project that onto their process.

Usually, a process starts something like, as I mentioned already, the initial project conception or the definition phase. What we try to often do at that point is we make sure that we try to engage people with disabilities right then. Because what we want to do, as much as possible, is make sure that we take into account any of their existing content needs, or things that they need that may be different than people without disabilities.

I love Indi Young's mental model, her approach to this in terms of finding out how people think about problems. I really find that to be a useful tool. Going through that mental model creation process with people with disabilities actually helps us determine what kind of content they need.

As an example, we find that somebody might be creating a mental model about how people decide what movie they're going to go and see. There are decision making factors that come into that process for somebody that has a disability that people without disabilities just don't even take into account.

A person with a disability would need to know if, for example, there was captioning available in that particular movie that they wanted to see. They need to know whether or not they can easily get there through public transit and not just the regular public transit, but somebody in a wheelchair.

They may have, I know certainly here in Ottawa, we've got a dedicated service called ParaTrans, which is like the equivalent of public transport but for people with disabilities. The ParaTranspo folks, there's an entire dependency on that system there for a person with a disability, physical disability, to actually go to the movies in the first place.

There are all these other decision-making factors that come in to it. And those types of things are really important to get out on the table right up front so that we not only know that we are creating an accessible design and an accessible implementation of that design, but that we've taken into account their content needs so that it actually takes their goals and objectives into account and that we haven't created something that's perfectly accessible but doesn't do anything to meet their actual needs.

We usually start at that phase, and we try to make sure that we include people with disabilities in any user research that we're doing, include people in the design iteration phase. We want to test colors and concepts. Particularly in the design phase testing iconography is really useful to do at a design phase. You can test that with paper prototypes and wireframes and things like that. You don't to need to have a fully coded interface.

And then, of course, one of the things that we always try to encourage is people do actual facilitated user testing with people with disabilities after you've gotten to a stage where things have been built to a certain extent. We don't want to test with people too early because it's just not necessarily productive. We don't want to leave it too late so that we can actually catch things during iteration.

So there's a few key points where we tend to look at things and that's sort of the project conception phase, during the user research and the design phase, and then during and after the development and implementation phases.

Adam: Now you told me before we started the recording here that you've actually been doing lots of research on how accessibility and responsive web design fit together. What can you share there?

Derek: It's really interesting. You know, there are a lot of people that are talking about the relationship between these two, and that responsive design is accessible design, and that accessibility and responsive are really two peas in a pod. And I think there's a certain amount of truth to that.

Philosophically they kind of have that same core idea in that we have this digital medium, and we want to insure that what we create is as flexible as it possibly can be to fit the environment in which it's being used. And that's one of the kind of fundamental pieces of responsive design is that we've got this inherent flexibility in the medium, and that's been something that accessibility advocates have been talking about for quite some time.

And so this whole idea of creating responsive designs that are more flexible and fit the containers and the devices that they're being displayed on that's actually a really powerful concept, and that flexibility is something that we've always been striving for in accessibility. So philosophically they're very much the same.

We're finding now, though, in actually going through -- now that we're seeing a lot of mainstream sites that are becoming responsive, and we're seeing clients that are coming to us saying, "We want to engage you in terms of accessibility, but how does that have any impact on what we're doing from a responsive perspective?" we're actually getting people that are actually implementing responsive designs.

And we're seeing some really interesting artifacts of that in that the testing -- this literally happened yesterday -- where a technique was being used to make this design work was actually causing something to break. And we're probably going to probably publish a test case on this, but ultimately it meant that one of the changes in display in moving from landscape to portrait mode caused an element's display to change on the screen.

This is difficult without actually showing you the example, but the display of a particular component on the page displayed differently when it was in portrait versus landscape mode, and that caused a change in interaction to be required, and it meant that when we were testing that particular component -- it was a navigational menu -- where the interaction for that menu changed, the source order for that menu needed to change in order to accommodate the different interaction and the different visual display, but the source order didn't change.

And what it meant was that the navigation no longer worked when we were in portrait mode. In landscape mode it was fine, but now when we switched to portrait mode the navigational component just completely stopped working properly simply by changing the orientation of the device.

And that kind of thing was really kind of an eye opener for us. You would think that the source order is the source order, but in that particular case the interaction, because the visual design changed and the interaction design changed, we actually needed to make a change to the source order in order to appropriately accommodate somebody that was working with assistive technology.

Adam: In the early part of the seminar you talked about functional needs in personas and other design artifacts. Can you give our audience some examples of that?

Derek: Yeah. I think we tend to avoid creating personas that are about somebody that's blind or about somebody that is deaf or that is hard of hearing. We try to focus, for example, on the functional side of it and the functional side of somebody that happens to be blind and is using a screen reader.

One of the most significant functional needs that they have is full keyboard access. So quite often we build those kinds of things into a persona rather than saying this happens to be a person that is blind, or creating the entire persona about this person that happens to be blind.

What we try to do is build the persona the way that we would otherwise, and then add on those functional needs and say -- we might not talk about James who is blind. We might talk about James, the admin assistant for such-and-such person. Or we might talk about -- I don't know why this name came to mind -- Adam. We might talk about Adam who is producing a podcast for somebody, but he actually is blind and needs to have full keyboard access to the recording software.

So we would do things like that rather than it being about Adam the blind person. It's about Adam the podcast producer who has a functional need that happens to include full keyboard accessibility.

And one of the reasons that we do that quite often is that we want people to realize that just because somebody happens to be blind or hard of hearing or has difficulty using a mouse and uses voice recognition software, their functional needs are essentially the same, because they're trying to accomplish the same goals with a piece of software or a website as everybody else is. They just have a different set of tools to do that.

So we want people, when we're talking about accessibility, to realize and to understand that really what we're talking about is not somebody having the goal of using their screen reader, but the goal is to accomplish a particular task and they just happen to be using a screen reader to do it or some other piece of assistive technology or something that requires a particular functional need, like full keyboard usage.

Adam: Talk a bit about finding people with disabilities that you can work with early in the process.

Derek: Sure. That's something that comes up quite often when we're talking with clients or even when I'm giving talks at conferences. People will ask exactly that question. Where do I find people because I don't even know where to start?

One of the places that we always suggest people look is at the local college or university that happens to be in the city or town nearby, because almost every single one of them -- in fact, I would say every one of them -- has some type of an office or center for students with disabilities and there's an incredible number of people that are already connected there, people that are maybe assistive technology specialists or combination specialists that work at these colleges and universities and they are already working with people with disabilities every day and they can be a great source of folks that have disabilities, partly because they already know them all, but partly because one of their mandates is usually to help provide people with disabilities with employment type opportunities.

So that's something that I think is really kind of a critical piece is getting people with disabilities from either the local college or local university or even if you're not comfortable going to those places, local advocacy groups. There are usually chapters for different disability groups.

I know here in Canada we have the CNIB which is our national organization that takes on advocacy issues for people that are blind or have low vision. There are local chapters in major cities around the country and similar organizations exist in all countries around the world for people with disabilities, or certainly in many countries anyway.

So those are two great sources for working with people with disabilities right from the beginning of a project.

Adam: What about quality assurance? How do we get them involved in the process?

Derek: So I think it's really important to validate all the things that we've done when it comes to accessibility remediation and testing. And it's one thing for accessibility people that are really familiar with accessibility and how people with disabilities use the web. It's one thing for them to be checking on things, but it's a whole other level for people that actually use the software and have specific disability needs or specific accessibility needs to use things like they're actually going to try and complete a task, like they're really trying to use the site and we're not just talking about straightforward walkthroughs, can I complete this task in a quality assurance type manner.

So what we want to do is involve certainly QA teams, but also involve people with disabilities in that QA process where they're actually walking through and doing this in literally just like a usability study that you would do, just doing the same type of things where we're asking people with disabilities to do walkthroughs and engaging them in testing specific processes and flows within applications or sites.

That's really the test. We can make sure that everything is technically accessible, but what we really, really want to do is make sure that it's not just technically accessible, but it's also really easy to use and those nuances and those little tiny usability nuggets that you'll pick up in doing real testing with real people that actually have disabilities and are not just doing things from a QA perspective, those nuggets are incredible because they take your interface from being something that allows people to accomplish tasks to being something that is actually more pleasurable to use and actually makes it so that the interface is actually something that's enjoyable and really easy to use and very efficient and streamlined.

Adam: Let's talk about one of those specific accessibility needs. Talk a bit about how people with low vision use their computers. That seemed to come up a lot in the questions that folks were asking during the seminar.

Derek: Yeah. It's interesting, because the beautiful thing about accessibility is that there is no black and white. Everything is a shade of gray to some extent. There's no accessible or not accessible, and when we're talking about people with low vision, there's such a huge variety in terms of what degree of low vision people have, their needs range so much that it's really kind of difficult to pin down exactly what a person with low vision is going to do with their computer.

Some people that have moderate low vision where it doesn't affect their visual acuity that much, they might be able to get away with just changing some operating system level settings where they make everything a little bit bigger. So we've seen, for example, somebody on a 27-inch monitor that is running at 800x600 resolution on that 27-inch monitor. They don't need to use magnification software. They're just changing something within the operating system so that they can see things a little bit better and they don't need a lot of accommodation other than that.

For other people, it's not about size. It actually ends up being about color scheme. They need to, quite often, change the color scheme on their computer. They might drop into high contrast mode, because it's much easier for them to read white text on a black background than it is to read black text on a white background.

On a case where you've got low vision, an entire screen of white, when you're reading black text on an entire screen of white, what your eyes need to detect is the absence of light. Whereas, when you're looking at it on a black screen with white text, you're detecting the presence of light, versus the absence. So, your eyes are not drenched with the full screen of white, they're only being presented with the white letters.

That is a significant difference for some people in that they need that alternative color scheme. It's not so much about the size, but it's about the colors that are being used to present information.

Some people will have greater degrees of low vision, where it's profound low vision, and they need different pieces of software. They might actually use a combination of a magnifier, so that they can see the interface and read some of the text. But then they might also use that in combination with reading software, so that when they find the text that they want to read, maybe they're looking at a newspaper website and they found an article that they wanted to read.

Well, what they can do, then, is find the text that they want to read by using their vision in a magnifying scenario. Then they can give their eyes a rest, highlight the text that they want to read, like the entire article, and they can tell their software to read it to them. They might use a combination of magnification and reading functionality so that they can use their eyes to find the thing that they're looking for, orient themselves, and then once they've found it, use reading software in order to give their eyes a rest.

There's a lot of variety in the way that people with low vision use the web and use their computers. I think that's one of the things that I love about the low vision problem. Many people in the accessibility field are really familiar with, and even web developer that aren't accessibility specialists have a decent sense of what it might be like to use a screen reader and what it means to develop an accessible application or site for somebody that uses a screen reader.

But low vision is a completely different problem. I find that the low vision issue is actually really kind of exciting and intriguing, because it's so very different than screen reader usage, in many ways.

Adam: People have bought in, right? Either it's because there's this fundamental, I get that accessibility is super important. Or they've heard you talk and understand that by focusing on accessibility earlier, you can actually create a better design, a more delightful design. How do they get buy-in with their organization, other stakeholders, a client? How do you pitch that process happening earlier?

Derek: That's an interesting one and something that we've started to see with many of the projects that we work on. One of the things that we've found that works reasonably well, and I'm not going to say that this works every time all the time, but one of the things that we do in as many cases as possible is we use accessibility to help solve other people's problems.

What I mean by that is, one of the things that is required for accessibility is a standard approach to design patterns and to development patterns. One of the things that accessibility can do is it helps bring about standardization and using standard methodologies and standard ways of solving particular problems.

I'm talking about interface widgets. Let's say we want to use a dialogue box in a web based interface. Well, we can use accessibility to say, here's an accessible way to do it.

Once that method, that widget has been approved from an accessibility perspective, that is now something that reduces development time because it means that that approved widget is also something that can be put into a repository that anybody can use.

That means that the next time you need to create a dialogue box widget, we don't go back and reinvent the wheel. We actually go to the, for lack of a better term, accessibility approved widget that has already been vetted, that has already been tested, and we can take that and build it right into the environment.

When we do things like that, we start to help the overall process of web design and development happen in the first place. That's really the kinds of things that we mean when we're talking about using accessibility to help solve somebody else's problem. Because the last thing that any manager wants is to have 30 different variations of a dialogue box scattered throughout the application, because that just makes it a maintenance nightmare for everyone.

If we can bring some of that standardization into things and use that as part of process and development strategy, then that can really help make the case for accessibility, both on a management level, but even higher up and getting people to buy in. Because, not only is the accessibility the right thing to do, but it also helps reduce costs, helps ease maintenance and helps the organization get things done quicker.

That's one of the examples, anyway, where you can certainly use accessibility and leverage it to get some buy-in from levels higher up.

Adam: Well, that's awesome. Derek, thanks for joining us again today.

Derek: Oh, absolutely. Thanks for having me, and we'll definitely talk again.

Adam: To our audience, thanks for joining us, and for your support of the Virtual Seminar program. Goodbye for now.