Author Archives: Sarah Horton

In this premiere episode of A Podcast for Everyone, UIE’s Adam Churchill interviews Sarah Horton and Whitney Quesenbery about their book, A Web for Everyone. They describe their journey in creating the book and share their perspectives on the importance of accessible user experience. They also provide suggestions for how product teams can use the book to support their practice. At the end, they introduce A Podcast for Everyone, a companion to the book, and give a preview of what they will be talking about in upcoming episodes.

• Episode 1: Introducing A Podcast for Everyone (mp3)
• Subscribe to A Podcast for Everyone on iTunes
• A Podcast for Everyone feed (xml)

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Resources mentioned in this podcast

• A Web for Everyone book site
• Access by Design book site
• Web Style Guide book site
• Storytelling for User Experience book site
• Global UX from Amazon
• Center for Civic Design
• Universal Principles of Design from Amazon
• Principles of Universal Design
• Section 508 Refresh
• Web Content Accessibility Guidelines

Transcript

Adam Churchill: Hello, everyone. Welcome to the first in a new series of recordings we’re calling “A Podcast for Everyone.” The concept for this podcast comes from Sarah Horton and Whitney Quesenbery, co-authors of “A Web for Everyone,” their new book from Rosenfeld Media. Whether you’re in charge of the user experience, development, or strategy for a website, “A Web for Everyone” is sure to help you make the site accessible without sacrificing design or innovation. I’m Adam Churchill, your host for this companion podcast.

A bit about our authors. Sarah Horton is director of accessible user experience and design for The Paciello Group. She works with companies and product teams to create born accessible digital products and services that work well for everyone. She’s also the author of “Access by Design” and co-author of “Web Style Guide” with Patrick Lynch.

Whitney Quesenbery combines an obsession to communicate clearly with her goal of bringing user research insights to designing products where people matter. Her previous books, “Storytelling for User Experience” and “Global UX,” helped practitioners keep users in mind throughout the creative process. She’s the co-director of the Center for Civic Design.

We thought it made some sense to open the podcast series with the authors talking a bit about what they learned putting this book together, the journey of people who will read it, and the plans we have in the works for future podcasts in this series. Welcome, Sarah. Welcome, Whitney.

Whitney Quesenbery: Hi, Adam.

Sarah Horton: Hi, Adam.

Adam: Accessibility. It’s a huge topic. Can you talk a bit about how you organized it for the book?

Sarah: Sure. We started off our conversations right away talking about organizing the accessibility topics around guidelines, because we personally are very much in favor of working around guidelines and principles — so much so, actually, that early on in our calls, we would have “getting to know you” calls because Whitney and I knew of each other but didn’t know each other well. We would talk through our different ideas for the book.

On one of the calls, we had this great moment where — they were video calls — I was talking about a particular book that I’m very fond of called the “Universal Principles of Design.” I was saying, “I really want to write a book like this. It lays things out so clearly, it’s so obvious, and there are these great illustrations.”

Whitney was like, “Wait, wait, wait, wait!” It was a video chat. Suddenly, she ran off screen, and I’m sitting there going, “Where did she go?” She comes back and she has her copy of that book held in her hands. From that moment on, I feel like we really hit a great synergy around this notion of guidelines as guiding the discussion.

We also wanted to talk a lot about people and have these guidelines come to life by bringing people into the discussion, so Whitney did a lot of work preparing the personas for the book. Maybe you should speak about that, Whitney.

Whitney: Sure. I come from a theater background, so the idea of making characters is pretty easy for me. Also, I think personas add something that’s often missing in discussions about accessibility, which is the people and their lives.

We often think about designing for someone who’s blind or designing for someone who’s deaf, but we don’t think about designing for Jacob. He’s a paralegal, he’s an equipment geek, he loves new tools, and, by the way, he happens to be blind. Blind is the last thing about him in his mind. It’s not the only thing we should be thinking about.

We should be thinking about everything about the person. Personas are a great way to show that. Now, no set of personas can represent the entire universe of people. There are many, many different variations of human beings in the word. But we picked eight of them that we thought represented the range of design considerations that you need to think about when you’re thinking about designing for a broad range of people.

They’re in the book. They’re also on the website. They helped us focus on who the audience was — not the audience for the book but the audience for design — and we hope that they’ll help other people as well.

Adam: With both your backgrounds, really broad and diverse experience, why accessibility? What was the goal in writing this book, and did that change at all during the process?

Sarah: I’ve been working in interaction design and user experience design for, good lord, a long time. I have been doing accessibility work sort of in parallel; but haven’t brought them together in the way that I think they need to come together. One of our goals in writing the book, particularly with the structure that we were using, is to bring universal design principles and accessibility together as an approach to moving forward with building accessible designs.

Universal design is an approach to design that takes into account the needs of everyone in making design decisions. It’s a very attractive way as a designer to look at accessibility so that you’re not thinking about accommodating people who are blind or accommodating people who have mobility issues, but rather building a product, a space, a park or a potato peeler that is going to be usable by everyone.

As a designer, that approach to accessibility is very attractive because it involves elegant design solutions as opposed to accommodations.

Adam: Whitney, how about for you?

Whitney: I’m probably pretty typical of a lot of people working in Web design and user experience. I thought accessibility was good. Of course we should do it! It seems like a generally good thing to do. But it wasn’t anything I really paid attention to.

What got me engaged in it was the work I’ve done around elections and ballot design. I started hearing people pit the needs of voters with disabilities against, say, security needs as though they were in opposition instead of saying, “We are bright, clever, innovative people. We can do great work that meets both technical requirements and human requirements.”

I don’t think this is that different than the battles that the early usability pioneers had. To say, “Look, it’s great that these computers exist, but let’s make them work for humans.”

The other thing that I see these days in UX is a really deep well of a desire to do good, as a designer to make things that change the world in positive ways. Some of us occasionally get to work on big projects. A lot of our work is routine.

One of the nice things about the way we’ve approached accessibility is that we’ve said accessibility is part of user experience. If you are thinking about people as you make design decisions, then you’re just doing design, but you’re doing it for a broader range of people. You’re doing it for more people.

Just like we think about diversity of devices these days — a laptop screen, a big computer screen, a tablet, a small screen, that’s one dimension of diversity — accessibility is really about how we interact. A screen reader, a mouse, a keyboard, or a specialized keyboard is another dimension of diversity.

Including that in our design work from the beginning rather than saying, “I finished my design. Now let’s sit down and make it accessible,” what Sarah was calling accommodation, where we layer it on afterwards. I’m trying to figure out how to help people think about this stuff from the beginning.

Adam: You’ve created what you call the accessible UX principles and guidelines. What is that and why is it important?

Whitney: Sarah was talking earlier about how we both really like the idea of principles and guidelines. I think it’s because principles are a way of thinking. They’re a starting point for how you think about it.

Too often we think about both usability and accessibility as checklists. “We have to do this, we have to do that. Let’s check off the things.” Trying to shift that to think about user experience principles that broaden out to be accessible. Again, it’s about designing it in and about changing the way we think about design rather than just giving us yet another checklist.

Adam: Sarah, tell us why “accessible UX”? Why is that the name?

Sarah: When we started the book, we had planned to map accessibility to the universal design principles. That’s what we had proposed, and that was our plan going out the door. As we worked on the book, it morphed into something other than what I think either of us expected at the start.

Because we were working with the universal design principles as well as the Web Content Accessibility Guidelines, principles, and success criteria, we ended up doing a lot of mapping, reshaping and rethinking of these existing guidelines and principles into something new. In a sense, we reshaped them such that they became a new set of principles and guidelines, which we’re calling the Accessible UX principles and guidelines.

It was a very organic process that, I think, surprised both of us a bit at the end, because we hadn’t really initiated the project thinking that we would end up with a new road map and a new way of looking at accessibility within the context of user experience.

Whitney: That’s right, Sarah. I love the principles of universal design, but they’re really designed for architecture. They started out thinking about buildings, things like ATMs on the side of buildings, physical spaces.

Digital spaces are different. There’s a lot of overlap between surface design, physical design, and digital design, but we think about them a little bit differently. We wanted to make sure that what we were creating was something that would fit into the process of how digital products are created.

Adam: Whitney, can you talk a bit about the big question of who’s responsible for accessibility?

Whitney: Yeah, that’s a good one. The answer is everyone. Of course, that’s our answer to everything — it’s a Web for everyone, and everyone is responsible.

We thought about the big areas. There’s that up-front research and design component, planning what it’s going to be. There’s content, figuring out how it’s going to work. You might add interaction to that. There are the developers.

Those are hard to separate in digital products. If you design something that’s hard to build accessibly, then you end up with something that’s kludgy. If you build something in a way that doesn’t express the design well, you end up with something that’s kludgy.

It’s about making sure that everyone is part of the process all throughout the process as opposed to just coming in and doing their little piece.

Let me give you an example from research. You might think that user research is pretty usual. “We’re going to find people in our audience. We’re going to use one of the many, many techniques in our toolbox to investigate them.”

But to make that into accessible UX, you can ask the question, who’s included in the research? Are we reaching out to include the voices and the needs of people with disabilities, older adults, or children? Are we only thinking about people who are “like us,” or have we reached out beyond that? Maybe to people who are bilingual or who happen to be getting old and their eyes aren’t as good as they used to be. When they’re included in the research, then their voices are included in our design process.

When we start thinking about teams, then it’s a whole bigger question. It’s not just one discipline. Sarah, you’ve done a lot of work helping teams learn how to build accessibility into their overall process. Maybe you could talk about that a little bit.

Sarah: That’s definitely an important aspect of this. The days are gone where you had one person doing everything from soup to nuts. Now we’re working on these interdisciplinary teams with different people responsible for different aspects of a project.

One thing that was very important to us in the book was to make sure that everyone involved in the product development team understood how the decisions that they are making affect someone else’s ability to build and make good decisions that are going to be accessible and provide an accessible user experience.

That was a very important aspect in the book, and one thing that, moving forward, if we’re actually going to build products with built-in accessibility and born-accessible products, everyone has to know how the work that they are doing is going to affect the next person involved in the product.

For example, if you’re building a layout or a design that’s going to be difficult for the developers to code in an accessible way, then you need to understand those constraints and build a design that is going to be aided by accessible coding practices.

Adam: We know that lots of teams are being faced with this challenge. They’ve never thought about accessibility before. All of a sudden, for what ever reason, they’re being challenged to make their sites and their applications accessible. Sarah, where do they start, and what are some things that they can do that will have the biggest impact immediately?

Sarah: That’s a really good question, Adam. The one thing I would say is that there are a lot of things that can be done at the code level to make a website or application have technical accessibility in the sense that all of the information that’s needed to make an interface functional and usable, a lot of that takes place in the code of a page.

If a team were to get started, I would suggest making as many fixes to the current implementation of the product to make sure that that underlying code does provide the information necessary.

Often, design related adjustments are much harder to make, because there’s a lot more that goes into that. At least in the work we’re doing, whenever we’re suggesting that a team rethink an approach to a design or an interaction, those changes are harder to make and take longer. There are more stakeholders involved.

There may have been a lot of usability testing that had been done for that particular implementation of a design. Those are harder to make. But the decisions about the code? Those you can go ahead and implement, and only have a positive effect on all users.

Adam: Whitney, what about when your clients turn to you? Anything additional that you offer?

Whitney: I want to second everything that Sarah said but add something else, which is that we often we often forget about content — the stuff in the middle of the page that we came to the site for, whether that’s a product catalog or information. There’s a lot we can do with that. It’s harder to change and fix maybe in a built site, a site that’s already existing.

Beginning to think about content. This stuff is simple. It’s using headings purely. A heading helps you find your way through the code. It’s the landmarks on the page. It’s making sure that the style sheet presents those headings well, they’ve got good colors.

If we think about headings, if we think about alternative text for images, and we think about making forms accessible, those get you a long way into fixing the content, whether you’re going back and cleaning up old content or starting again with new content.

That often feels more daunting. Many organizations have many different people writing information. It feels like you have to get a large team going. But that work is important. Even things like simplifying languages or putting in bullets makes a huge different to people who don’t read very well or are reading on a tiny screen. They make it easier for people to use the things you put out on their site for them to use.

Adam: “A Web for Everyone,” a fantastic resource for design teams. Sarah, can you talk a bit about how design teams are using the book in their work?

Sarah: One way that people are using the book and that teams are using the book relates to what I was talking about earlier in terms of having everyone understand how the project works together, and how decisions are made collectively and how they impact one another. That’s an important facet of the book because it highlights everyone’s role at the different points in the development lifecycle.

Another way that the book is being used. Also, we have resources right now on the website. The personas are among them. I recommend people have a look at those right away because those are personas that you can go ahead and start using to bring people with disabilities into user research discussions.

The personas were mainly done by Whitney. I have to do kudos to Whitney because I think they’re one of the strongest components in the book. The illustrator, Tom Biby, did a fantastic job working with us to get them to be the type of personas that we wanted to represent in the book and on the website.

The personas are already there for use. I recommend that folks have a look at them, download them, and start using them in your work.

Whitney: We tried to pack it full of examples and the kinds of things you think about at each different aspect of design. Even though it’s principles and guidelines, they’re meant to be inspirational. They’re meant to be things that will help you think about how to do your design better.

Adam: I have to ask this question, because it seems to come up at least here in the United States. There’s talk of compliance. As guidelines, should you follow 508 or WCAG?

Whitney: Let me explain what those are. 508 is our shorthand name for the US federal requirements for accessibility, and WCAG stands for the Web Content Accessibility Guidelines from the W3C, which is also a set of requirements and guidelines for accessibility.

The answer is that we think you can actually focus on WCAG. The federal government is about to update the 508 regulations. What they’ve announced they’re going to do, they’re going to say that if you follow WCAG, you will be following 508. We’re beginning to see these two important legal requirements converging.

The other thing that we did in the book was we have a crosswalk between the WCAG guidelines and principles and our guidelines and principles so that you can see how the things fit together. For example, there are requirements in WCAG that affect both the visual design and the content design. We’ve got them in both chapters. You can see how two teams, for instance, might tend to coordinate their work in order to meet those requirements.

Adam: At the beginning, we teased all the great plans we have for this podcast. Can you tell our audience what they can look forward to?

Whitney: First of all, you’ll hear a lot less of us and a lot more of other people.

Sarah hasn’t mentioned something in the book that is also important. We have interviews with people who were influential in our thinking. We want to continue that process.

There are a lot of people working in this field doing awesome work, often developing interesting tools and techniques that we can use. We’d like to introduce them to you. We’ll be bringing them in and picking their brains for practical, useful things you can put to use in your work.

Adam: Very cool. It’s super exciting. We’re looking forward to hearing what you broadcast with us in the near future.

Thanks, everyone. Thanks to our audience for listening in, and a special thanks to our sponsors, UIE, Rosenfeld Media, and The Paciello Group, for making the series happen.

Be sure to follow @AWebForEveryone on Twitter for information about future “A Podcast for Everyone” plans and availability. Goodbye for now!

An edited version of this interview appears in Chapter 6 of A Web for Everyone.

Steve Faulkner has been an accessibility engineer since 2001, first with Vision Australia and currently with The Paciello Group. He has a hand in developing HTML5 and WAI-ARIA specifications as a member of W3C working groups, and is editor of W3C specifications on HTML5, Using ARIA in HTML, accessibility APIs, and text alternatives. In short, Steve has accessibility chops.

Because much of what’s needed is beneath the surface of a page, we asked Steve to explain what user experience designers should know about how code supports accessibility.

Elements of an accessible user interface

Web accessibility is largely about providing the information needed to make a user interface accessible to assistive technology, or AT. This is accomplished via an accessibility application programming interface, or API–a standardized way of specifying elements of an interface. A primary goal of an API is interoperability, where different devices and software can all use the same elements. For accessibility, Steve explains, “One piece of the puzzle is for information to be defined by an accessibility API. The second piece of the puzzle is for AT to make use of it.”

For the web, every HTML element has a role, states, and properties that are defined in the technology specification–“What it is, what it does, and where it’s at, at this point in time.” That information is expressed by the accessibility API in the browser, so that assistive technology can make use of it. “For example, with a heading, one of the properties might be its level, and whether it’s editable, visible, or linked.” The role, state, and properties information in the accessibility API allow assistive technology to, for example, create a list of headings or move keyboard focus to the main heading of a page.

Unfortunately, browsers and assistive technology don’t always make use of the accessibility API. “We’re always told to use <strong> and <emphasis> rather than <b> and <i> because they have semantic meaning, but the semantic meaning is not consumed by anyone” because browsers and assistive technology don’t make use of the information.

An accessibility API needs more than HTML

There are gaps in how native HTML elements support the accessibility API, because of how they are specified and how they are used. “Some decisions about what goes into HTML and what doesn’t don’t take into account accessibility requirements.”

For example, the role “main” is not represented in the HTML5 specification as an element, despite the expressed need for AT users to move cursor focus to the main content area. Other roles are defined, such as header, footer, and navigation: “I guess the thinking was, anything that’s not something else must be the main content.”

Also, HTML elements are not always used correctly. As an example, Steve explains that HTML buttons have been part of the specification for 15 years. However, developers build custom buttons using elements like images and links that are coded to behave like buttons. Typically, this is because of constraints imposed by visual design requirements. “They have to please whoever makes the design decisions. To achieve a certain visual effect across different browsers and platforms, they can’t always use standard controls.”

In these cases, HTML cannot provide the necessary information to make the interface accessible. “WAI-ARIA is the only way to supplement the necessary information for assistive technologies.”

WAI-ARIA fills the gaps

WAI-ARIA fills out the accessibility API, enhancing the descriptive information contained in native HTML controls and back-filling information for elements that are used for other than their intended purpose.

For example, ARIA provides explicit roles and properties to assist in wayfinding for users of assistive technology. Like “stepping stones,” ARIA landmark roles allow assistive technology users to step through the content of the page to find the content area of interest.

As with most accessibility features, information provided for accessibility could be of use to all users. “ARIA landmark roles would be of great use to users who navigate by the keyboard, but the roles are not exposed as navigable elements by browsers.” Assistive technology makes use of the roles, but as of this writing, no browser does. Another possible application would be to dim regions of the page that do not have focus in order to reduce distractions. Landmarks could also be used in the print view of a document, providing users with the option to hide elements like navigation that have little use on paper.

Accessible code in the real world

Steve is editor of four W3C specifications: HTML 5.1, Using ARIA in HTML, HTML5: Techniques for Providing Useful Text Alternatives, and HTML to Platform Accessibility APIs Implementation Guide. To inform his work, he started a data-mining project in which he downloaded the home pages of the top 50,000 websites and began analyzing how designers and developers were using elements, specifically HTML5 and ARIA code. “Those of us who develop standards define how things should be used and hope that developers follow the guidance so users get the benefit. But unless we actually look at the way they are being used, we can’t know whether they are actually being used in the right way.” His hope is that, by analyzing and identifying patterns of real-world code, he will be able to provide more practical guidance.

For example, in HTML5, there’s a new “placeholder” attribute that allows you to display a hint in a text field, such as “Enter your first name.” Some sites use “placeholder” as a field label, in place of the <label> element. In this case, Steve can recommend that browser’s use “placeholder” in “accessible name calculation” to convey information to assistive technology users about form fields.

Steve is also learning how much and how effectively HTML5 and ARIA are used in mainstream websites: for example, how ARIA landmarks, such as role=”main”, role=”banner”, and role=vcontentinfo”, are implemented. While he found that usage was low, he was “both surprised and pleased” to find that landmarks are being used correctly. “The specification says, for certain landmarks, you should have one per page, and overwhelmingly they are being used per specification, with one per page.”

HTML5, ARIA, or both?

In general, support for ARIA is more robust than accessibility support for new HTML5 features, due to its age and attention paid to getting ARIA support in mainstream tools. While ARIA has been providing landmark support since 2006, as of this writing, the HTML5 spec is still in the works. In addition to maturity, ARIA has benefited from successful collaborations between accessibility experts, such as IBM, and browser and AT vendors, such as Firefox and Freedom Scientific.

As a result, ARIA support is strong in most software. “I’m not saying that it’s good across the board, mainly due to some AT vendors just putting their heads in the sand, which has the effect of doing a disservice to their users.” And you can count on support for ARIA into the future. “As far as ARIA is concerned, it will remain relevant for many years to come. As new issues and technologies emerge, there will be new related updates to the ARIA specs to fill in any gaps.”

It’s best to think of ARIA as complementary, with HTML providing the core elements and ARIA filling the accessibility gaps as needed. “A good rule of thumb is, when there’s a native HTML structure, element, or attribute that’s well supported, use it. If that’s not enough, use the appropriate ARIA semantics.” But Steve also points out that there’s no harm in using both HTML5 roles and ARIA landmarks, such as <nav role=”navigation”>, where <nav> is an HTML5 element and the attribute role=”navigation” is an ARIA landmark role.

Advice for project teams

Steve encourages developers to go ahead and add ARIA landmark roles to current projects. “The good thing about landmarks is that you can add them to your current code, and they don’t have any design effects.” For interactive widgets that provide complex interactions, he recommends looking to existing libraries, such as JQuery or Dojo–code with WAI-ARIA already built in.

But he also sees the need for a change in mindset in how designers build websites and applications. “You tend to find back-end coders developing front-ends without understanding what makes a user interface usable, let alone accessible.” This is because project efforts often focus on the business transactions that occur on the back end, with little thought given to the user interface. “HTML development is often seen as monkey work that’s given to junior developers, or given to back-end developers who tack the front end on, and they don’t understand how to develop a user interface correctly, they don’t understand how to use HTML correctly, and then you see applications built without semantics.”

On the design end, Steve urges designers to understand that design elements are not just “pixels on a page,” but rather semantic containers for information described in code. “I don’t think designers need to know how to code. They do need to understand that there’s a give and take between what can be done given the requirement to actually code.”

Overall, he believes that project teams must include user interface expertise. “What’s needed is the realization within a team of the value of having people who understand usable UI design and can bring it to fruition using the code.”

An edited version of this interview appears in Chapter 5 of A Web for Everyone.

Derek Featherstone is founder and lead of Simply Accessible, a consultancy that works to bring accessibility into organizations through consulting, training, workshops, and support. Derek is a well-known and well-respected advocate for accessible user experience, moving beyond technical accessibility to support good and successful experiences for everyone.

Interactivity is a complex challenge for accessibility, making sure sites and apps are operable in different ways on different devices. We wanted to learn from Derek how best to approach a moving target like accessible interaction.

People are the starting point

Concern for people is the primary driver for Derek and his colleagues at Simply Accessible. They approach projects from the user’s perspective, starting with questions such as: What do we already know about people who use the site? What are their goals and motivations? What is this page or screen here to help them accomplish?

From there, they consider how the design and flow impacts the success of people with and without disabilities. “It has to be about the people who are actually using the site or application to accomplish something. If it’s not about them, then what’s the point?”

Best accessibility techniques are constantly changing

Derek’s team works from a knowledgebase of accessible techniques, built over many years of user research and usability testing, learning how people use the web. Building on those known techniques, they use observation and experimentation to come up with better techniques for coding, designing, and writing content that improves the user experience.

A lot of our work is experimental, even if it’s not fully classified as experimentation. Every technique that we come up with is our best technique at the time, until something better comes along. There’s a constant iteration that happens in the techniques we use.

This iteration is core to their practice because there is always room for improvement when it comes to accessible user experience, particularly with interaction, where new widgets and modules regularly appear on websites and apps.

We see a problem, we find an issue, and we pop a message into the team Basecamp: ‘Here’s an issue we found today, here’s the behavior of the form or link or whatever, and here’s how we think we can solve it. Can you code it up?’ Then we’ll put it through technical testing to make sure it’s compatible with different assistive technologies. And then we’ll roll it out and test it with users with disabilities. A lot of what we do is that kind of iteration, trying to explore different techniques.

Technical remediation can help make interaction accessible

Most often, Derek’s team is called on to take an existing website or app and make it accessible. Often, the designs are visually rich and appealing, and they convey information and relationships among elements in a visual way. However, those visual details are not always in the code. “The designs don’t convey the same information under the hood as they do visually.”

Take, for example, social media sharing badges. Most are embedded within a page using iFrames, and can be difficult to understand and use for someone who can’t see what’s displayed on the screen. For instance, many don’t have alt-text that accurately reflects the contents of the badge, such as the state and status of different buttons. Visually, you can tell whether an item has been liked or shared, but the code doesn’t contain the same information.

Derek and his colleagues have been working on a script for making social media buttons and badges accessible, one that would make state and status information available in the code where it’s available to assistive technology. This accessibility add-on then becomes part of their toolkit, to use on projects that include social media buttons and badges. But they also hope to influence the makers of these elements to incorporate their techniques directly into the elements.

We know it would be better if these elements were natively accessible. We also know that change doesn’t happen right away. Both solutions are needed. We keep our fixes on file so we can use them while the people in charge of social sharing badges work on making them more accessible.

Derek prefers to build in accessibility rather than provide technical remediation. “Our entire team views accessibility as part of the overall user experience and not as a separate thing that needs to be done afterwards.” However, in practice, clients very often come to accessibility late in the process, when there is little hope of changing the course of the design to produce a more accessible outcome.

Quite often people come to us with a completed site that has already been approved by management. For us to look at something and suggest a design change ends up being quite difficult to do. What we usually do is say, given what you’ve designed, here’s what you need to do to make it work in a more accessible way.

Integrated accessibility produces the best outcomes

But in some projects, they are brought in early and remain part of the team throughout the project, through implementation and execution. Projects handled this way are the most successful.

“What it comes down to is having people switched on right from the beginning of the project. They understand accessibility as more than a technical checklist.” With an early commitment, accessibility becomes part of the well-established user experience practice, integrated into defining requirements, user research, and carrying through to design iteration and execution. “One of the most important things to achieve success is to have all accessibility touch points built into the process right from the beginning.”

Tools help teams integrate accessible components

Derek and his colleagues have worked on several large-scale projects, and have had good success providing teams with tools that made it easier to build accessible products.

Everybody is overwhelmed with work that needs to be done, the amount of work that needs to be done, and how soon it needs to be done. Everybody wants things yesterday. Our strategy is to give everybody the tools they need to get the job done.

Simply Accessible gives teams an accessibility guide, integrated into the organizational style guide or branding guide. They create a code repository and pattern library containing elements such as modal dialogs or tool tips that can be easily dropped into code. The interactive elements are reviewed and validated for accessibility from a code, design, and testing point of view, including testing with people with disabilities.

One of our goals is to eliminate excuses. On projects, somebody makes choices about the timeline, and that means somebody else has to say, “We don’t have time for accessibility because we have this deadline of ‘x’.” We think about all the different pressures people feel when building a site and try to address them.

With this approach, communication is the greatest challenge. People working on the project need to know the requirement to use the library and other resources, and understand the implications of not using the tools. Otherwise, these resources may be overlooked or elements modified in such a way that the accessibility benefits are lost.

The most influential tool for accessibility is clear purpose

In cases where Derek has been able to influence design, the best tool in guiding an accessible process has been clear purpose–“Asking the original question, what is the purpose of this page and what are we trying to help people do.” In practice, we often use patterns and designs the way they’re always used, and add in expected features, without considering the goals and the necessary actions to support the goals. “That’s our most influential technique. And once we get answers, we can start asking questions like, how does somebody who uses voice recognition software because they don’t have the ability to use their hands, how are they going to activate that particular type of control?”

The #1 reason for them to use the site is to work with this widget, but they can’t because they’re using voice recognition software, and the widget is designed in such a way that the voice recognition software user won’t know what to do to activate it in the first place.

Starting with clear purpose and specific goals, the task is to design a solution that everybody can use to accomplish the tasks.

Solutions come from different places

Solutions aren’t always directly supported by design. In some cases, it’s the access technology that makes a design accessible.

Derek tells a story of a woman who needed a very specific design approach for accessible interaction. She was a quadriplegic, but had enough strength in one arm to lift her hand and operate a large touchscreen. “She didn’t have dexterity in her fingers, but she could make a fist and use the middle knuckle of her index finger to tap the screen.” Her greatest challenges in using websites were radio buttons and checkboxes, which were too small for her to activate accurately. Derek created a user stylesheet she could install in her browser that would resize radio buttons and checkboxes 10 times the size they normally appear.

“No designer would ever allow or think to include in their designs such large controls. It’s a solution that was only necessary for her.” But the story illustrates that accessible interaction isn’t about finding the one solution that works for everyone. “We can create one solution that works for most people’s abilities, but there are some people that need accommodation for their disabilities that a designer or developer can’t take into account in their work.” In these cases, the work of the designer and developer is to make the design flexible and adaptable. That way browsers and assistive technology can take elements of the design and adapt them to meet the specific needs of the user.