Jeffrey Zeldman

Una Kravets

Rachel Andrew

Eric Meyer

Jen Simmons

Jeremy Keith

Donna Lichaw

Trent Walton

Derek Featherstone

The latest in our series “The Tools We Use” features Trent Walton, co-founder of Paravel and part of the team behind sites like DayTrip and The Many Faces Of.
Atom: While I’m considering a switch to Visual Studio Code, Atom has bee…

The latest in our series “The Tools We Use” features Trent Walton, co-founder of Paravel and part of the team behind sites like DayTrip and The Many Faces Of.

Atom: While I’m considering a switch to Visual Studio Code, Atom has been my code editor of choice for years now, mostly because because my two teammates were using Atom when I was looking for a new editor. I’ll switch tools anytime I think it’ll make teamwork and collaboration easier. That said, I find that my needs/wants are relatively simple for code editors. Syntax highlighting for code and spell check for blogging make me a happy camper.

CodePen: Most projects I work on that start from scratch begin in Codepen. It’s a great coding environment, but the main reason for this preference is a collaborative one: nothing feels too sacred or precious when the code is right there practically inviting you to riff and edit. Casual exploration and regular collaboration can massively impact the quality of the final product.

BetterTouchTool: I customize trackpad and Magic Mouse inputs with BetterTouchTool. While I feel Jedi-like when I tap and swipe to export, refresh, app switch, etc., my coworkers would tell you it’s the most stressful thing they’ve ever seen.

Grammarly: While I don’t utilize the browser extension, nor do I believe there’s a substitute for a human editor, I use the Grammarly app to help ensure I’m explaining myself clearly. If I’ve been working on an email and get the sense things are getting muddy, I’ll paste my thoughts into the app for a little help untangling them.

ImageAlpha and ImageOptim: I try to never upload an unoptimized image to the internet.

Slack: We have a team Slack for Paravel, and we’re typically in one for every client/project we’re on. It’s a lot of Slacks!

Font Explorer X: For me, font management is a myth, but I do my best with Font Explorer.

I’ve also got a few tools that help me deal with third-party scripts, which is the subject of my talk for An Event Apart:

WebPageTest: I’ve been using WPT for years with a page speed focus, but recently I’ve begun using it to block specific domains and third-party services to get comparative data on their performance impact.

Ghostery: While it’s crucial to support sites and online publications you value, I sometimes find it necessary to use a content blocker while browsing the web. Ghostery is my favorite, primarily because the browser extension is rich with information about third-parties. Expanding the extension panel while browsing served as my intro to gaining a broad understanding of all the different types of third-party scripts and services out there.

Charles Proxy: To me, Charles Proxy is a GUI for analyzing .har files, but it’s so much more than that. You can use it to monitor HTTP and SSL/HTTPS traffic between your machine and the Internet.

It’s worth noting that while some of these tools might seem highly technical, my talk won’t be! I’ve spent the past 8-9 months researching third-party scripts and their multifaceted impact on the quality of a site, and I’ll summarize what I’ve found from a web designer’s perspective.

By Beth Raduenzel
Each month, A List Apart’s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading!—Ed.
The summer of 2017 marked a monumental victory for the …

By Beth Raduenzel

Each month, A List Apart‘s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading!—Ed.

The summer of 2017 marked a monumental victory for the millions of Americans living with a disability. On June 13th, a Southern District of Florida Judge ruled that Winn-Dixie’s inaccessible website violated Title III of the Americans with Disabilities Act. This case marks the first trial under the ADA, which was passed into law in 1990.

Despite spending more than $7 million to revamp its website in 2016, Winn-Dixie neglected to include design considerations for users with disabilities. Some of the features that were added include online prescription refills, digital coupons, rewards card integration, and a store locator function. However, it appears that inclusivity didn’t make the cut.

Because Winn-Dixie’s new website wasn’t developed to WCAG 2.0 standards, the new features it boasted were in effect only available to sighted, able-bodied users. When Florida resident Juan Carlos Gil, who is legally blind, visited the Winn-Dixie website to refill his prescriptions, he found it to be almost completely inaccessible using the same screen reader software he uses to access hundreds of other sites.

Juan stated in his original complaint that he “felt as if another door had been slammed in his face.” But Juan wasn’t alone. Intentionally or not, Winn-Dixie was denying an entire group of people access to their new website and, in turn, each of the time-saving features it had to offer.

What makes this case unique is that it marks the first time in history in which a public accommodations case went to trial, meaning the judge ruled the website to be a “place of public accommodation” under the ADA and therefore subject to ADA regulations. Since there are no specific ADA regulations regarding the internet, Judge Scola decided the adoption of the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA to be appropriate. (Thanks to the hard work of the Web Accessibility Initiative (WAI) at the W3C, WCAG 2.0 has found widespread adoption throughout the globe, either as law or policy.)

Learning to have empathy

Anyone with a product subscription service (think diapers, razors, or pet food) knows the feeling of gratitude that accompanies the delivery of a much needed product that arrives just in the nick of time. Imagine how much more grateful you’d be for this service if you, for whatever reason, were unable to drive and lived hours from the nearest store. It’s a service that would greatly improve your life. But now imagine that the service gets overhauled and redesigned in such a way that it is only usable by people who own cars. You’d probably be pretty upset.

This subscription service example is hypothetical, yet in the United States, despite federal web accessibility requirements instituted to protect the rights of disabled Americans, this sort of discrimination happens frequently. In fact, anyone assuming the Winn-Dixie case was an isolated incident would be wrong. Web accessibility lawsuits are rising in number. The increase from 2015 to 2016 was 37%. While some of these may be what’s known as “drive-by lawsuits,” many of them represent plaintiffs like Juan Gil who simply want equal rights. Scott Dinin, Juan’s attorney, explained, “We’re not suing for damages. We’re only suing them to follow the laws that have been in this nation for twenty-seven years.”

For this reason and many others, now is the best time to take a proactive approach to web accessibility. In this article I’ll help you create a blueprint for getting your website up to snuff.

The accessibility blueprint

If you’ll be dealing with remediation, I won’t sugarcoat it: successfully meeting web accessibility standards is a big undertaking, one that is achieved only when every page of a site adheres to all the guidelines you are attempting to comply with. As I mentioned earlier, those guidelines are usually WCAG 2.0 Level AA, which means meeting every Level A and AA requirement. Tight deadlines, small budgets, and competing priorities may increase the stress that accompanies a web accessibility remediation project, but with a little planning and research, making a website accessible is both reasonable and achievable.

My intention is that you may use this article as a blueprint to guide you as you undertake a DIY accessibility remediation project. Before you begin, you’ll need to increase your accessibility know-how, familiarize yourself with the principles of universal design, and learn about the benefits of an accessible website. Then you may begin to evangelize the benefits of web accessibility to those you work with.

Have the conversation with leadership

Securing support from company leadership is imperative to the long-term success of your efforts. There are numerous ways to broach the subject of accessibility, but, sadly, in the world of business, substantiated claims top ethics and moral obligation. Therefore I’ve found one of the most effective ways to build a business case for web accessibility is to highlight the benefits.

Here are just a few to speak of:

• Accessible websites are inherently more usable, and consequently they get more traffic. Additionally, better user experiences result in lower bounce rates, higher conversions, and less negative feedback, which in turn typically make accessible websites rank higher in search engines.
• Like assistive technology, web crawlers (such as Googlebot) leverage HTML to get their information from websites, so a well marked-up, accessible website is easier to index, which makes it easier to find in search results.
• There are a number of potential risks for not having an accessible website, one of which is accessibility lawsuits.
• Small businesses in the US that improve the accessibility of their website may be eligible for a tax credit from the IRS.

Start the movement

If you can’t secure leadership backing right away, you can still form a grassroots accessibility movement within the company. Begin slowly and build momentum as you work to improve usability for all users. Though you may not have the authority to make company-wide changes, you can strategically and systematically lead the charge for web accessibility improvements.

My advice is to start small. For example, begin by pushing for site-wide improvements to color contrast ratios (which would help color-blind, low-vision, and aging users) or work on making the site keyboard accessible (which would help users with mobility impairments or broken touchpads, and people such as myself who prefer not using a mouse whenever possible). Incorporate user research and A/B testing into these updates, and document the results. Use the results to champion for more accessibility improvements.

Read and re-read the guidelines

Build your knowledge base as you go. Learning which laws, rules, or guidelines apply to you, and understanding them, is a prerequisite to writing an accessibility plan. Web accessibility guidelines vary throughout the world. There may be other guidelines that apply to you, and in some cases, additional rules, regulations, or mandates specific to your industry.

Not understanding which rules apply to you, not reading them in full, or not understanding what they mean can create huge problems down the road, including excessive rework once you learn you need to make changes.

Build a team

Before you can start remediating your website, you’ll need to assemble a team. The number of people will vary depending on the size of your organization and website. I previously worked for a very large company with a very large website, yet the accessibility team they assembled was small in comparison to the thousands of pages we were tasked to remediate. This team included a project manager, visual designers, user experience designers, front-end developers, content editors, a couple requirements folks, and a few QA testers. Most of these people had been pulled from their full-time roles and instructed to quickly become familiar with WCAG 2.0. To help you create your own accessibility team, I will explain in detail some of the top responsibilities of the key players:

• Project manager is responsible for coordinating the entire remediation process. They will help run planning sessions, keep everyone on schedule, and report the progress being made. Working closely with the requirements people, their goal is to keep every part of this new machine running smoothly.
• Visual designers will mainly address issues of color usage and text alternatives. In its present form, WCAG 2.0 contrast minimums only apply to text, however the much anticipated WCAG 2.1 update (due to be released in mid-2018) contains a new success criterion for Non-text Contrast, which covers contrast minimums of all interactive elements and “graphics required to understand the content.” Visual designers should also steer clear of design trends that ruin usability.
• UX designers should be checking for consistent, logical navigation and reading order. They’ll need to test that pages are using heading tags appropriately (headings are for semantic structure, not for visual styling). They’ll be checking to see that page designs are structured to appear and operate in predictable ways.
• Developers have the potential to make or break an accessible website because even the best designs will fail if implemented incorrectly. If your developers are unfamiliar with WAI-ARIA, accessible coding practices, or accessible JavaScript, then they have a few things to learn. Developers should think of themselves as designers because they play a very important role in designing an inclusive user experience. Luckily, Google offers a short, free Introduction to Web Accessibility course and, via Udacity, a free, advanced two-week accessibility course. Additionally, The A11Y Project is a one-stop shop loaded with free pattern libraries, checklists, and accessibility resources for front-end developers.
• Editorial review the copy for verbosity. Avoid using phrases that will confuse people who aren’t native language speakers. Don’t “beat around the bush” (see what I did there?). Keep content simple, concise, and easy to understand. No writing degree? No worries. There are apps that can help you improve the clarity of your writing and that correct your grammar like a middle school English teacher. Score bonus points by making sure link text is understandable out of context. While this is a WCAG 2.0 Level AAA guideline, it’s also easily fixed and it greatly improves the user experience for individuals with varying learning and cognitive abilities.
• Analysts work in tandem with editorial, design, UX, and QA. They coordinate the work being done by these groups and document the changes needed. As they work with these teams, they manage the action items and follow up on any outstanding tasks, questions, or requests. The analysts also deliver the requirements specifications to the developers. If the changes are numerous and complex, the developers may need the analysts to provide further clarification and to help them properly implement the changes as described in the specs.
• QA will need to be trained to the same degree as the other accessibility specialists since they will be responsible for testing the changes that are being made and catching any issues that arise. They will need to learn how to navigate a website using only a keyboard and also by properly using a screen reader (ideally a variety of screen readers). I emphasized “properly” because while anyone can download NVDA or turn on VoiceOver, it takes another level of skill to understand the difference between “getting through a page” and “getting through a page with standard keyboard controls.” Having individuals with visual, auditory, or mobility impairments on the QA team can be a real advantage, as they are more familiar with assistive technology and can test in tandem with others. Additionally, there are a variety of automated accessibility testing tools you can use alongside manual testing. These tools typically catch only around 30% of common accessibility issues, so they do not replace ongoing human testing. But they can be extremely useful in helping QA learn when an update has negatively affected the accessibility of your website.

Start your engines!

Divide your task into pieces that make sense. You may wish to tackle all the global elements first, then work your way through the rest of the site, section by section. Keep in mind that every page must adhere to the accessibility standards you’re following for it to be deemed “accessible.” (This includes PDFs.)

Use what you’ve learned so far by way of accessibility videos, articles, and guidelines to perform an audit of your current site. While some manual testing may seem difficult at first, you’ll be happy to learn that some manual testing is very simple. Regardless of the testing being performed, keep in mind that it should always be done thoroughly and by considering a variety of users, including:

• keyboard users;
• blind users;
• color-blind users;
• low-vision users;
• deaf and hard-of-hearing users;
• users with learning disabilities and cognitive limitations;
• mobility-impaired users;
• users with speech disabilities;
• and users with seizure disorders.

When you are in the weeds, document the patterns

As you get deep in the weeds of remediation, keep track of the patterns being used. Start a knowledge repository for elements and situations. Lock down the designs and colors, code each element to be accessible, and test these patterns across various platforms, browsers, screen readers, and devices. When you know the elements are bulletproof, save them in a pattern library that you can pull from later. Having a pattern library at your fingertips will improve consistency and compliance, and help you meet tight deadlines later on, especially when working in an agile environment. You’ll need to keep this online knowledge repository and pattern library up-to-date. It should be a living, breathing document.

Cross the finish line … and keep going!

Some people mistakenly believe accessibility is a set-it-and-forget-it solution. It isn’t. Accessibility is an ongoing challenge to continually improve the user experience the way any good UX practitioner does. This is why it’s crucial to get leadership on board. Once your site is fully accessible, you must begin working on the backlogs of continuous improvements. If you aren’t vigilant about accessibility, people making even small site updates can unknowingly strip the site of the accessibility features you worked so hard to put in place. You’d be surprised how quickly it can happen, so educate everyone you work with about the importance of accessibility. When everyone working on your site understands and evangelizes accessibility, your chances of protecting the accessibility of the site are much higher.

It’s about the experience, not the law

In December of 2017, Winn-Dixie appealed the case with blind patron Juan Carlo Gil. Their argument is that a website does not constitute a place of accommodation, and therefore, their case should have been dismissed. This case, and others, illustrate that the legality of web accessibility is still very much in flux. However, as web developers and designers, our motivation to build accessible websites should have nothing to do with the law and everything to do with the user experience.

Good accessibility is good UX. We should seek to create the best user experience for all. And we shouldn’t settle for simply meeting accessibility standards but rather strive to create an experience that delights users of all abilities.

Additional resources and articles

If you are ready to learn more about web accessibility standards and become the accessibility evangelist on your team, here are some additional resources that can help.

Resources

• Interactive WCAG 2.0—an awesome full version of the WCAG 2.0 guidelines that allows you to filter success criteria by responsibility.
• tota11y—tota11y is an easy-to-use accessibility visualization tool from Khan Academy.
• The A11Y Project—a ton of libraries, checklists, and accessibility resources for front-end developers.
• Web Accessibility by Google: Developing with Empathy—a free two-week eLearning course that is geared toward experienced front-end developers.
• “Top Twenty-Five Awesome Accessibility Testing Tools for Websites”—a compiled list of twenty-five automated accessibility testing tools with a brief description of each one.

Articles

• “Why Designing for Accessibility Is Simply Good Business”—lists seven business-savvy benefits of having an accessible website.
• “Accessibility Is Part of UX (It Isn’t a Swear Word)”—an awesome article that addresses how the separation of HTML and CSS affects navigation, layout, and more.
• “Reframing Accessibility for the Web”—addresses negative stereotypes, ableism, and how to integrate accessibility into your testing process.
• “What Does Responsive Web Design Have to Do with Accessibility?”—discusses how responsive web design improves UX and accessibility.
• “Ten Guidelines to Improve the Usability and Accessibility of Your Site”—helps you identify the “low-hanging fruit” of accessibility issues and shows you how to fix them.

About the author

Beth Raduenzel is a senior interaction designer at Uptake in Chicago. Her previous work as an accessibility specialist at United Airlines helped earn them an AFB Access Award. Beth lives in the suburbs with her husband and two young sons. She enjoys photography, hiking and tweeting about web accessibility.

For more information every web designer and front-end developer needs, read A List Apart “for people who make websites.”

Illustration by Dougal MacPherson.