Web Accessibility — Consider These 6 Things Before Your Next Web-Project (Part 2)
This is the second in our two-part series on accessibility and web design. Part one focused on reframing perceptions and illustrating how accessibility can be profitable, too. In part two, we outline tactical steps to help make your projects more accessible, provide general guidelines and offer additional resources to explore.
In the first part of our series, we highlighted six components we believe you should consider when creating a more accessible web.
- Redefining What Accessibility Means
- Shifting Focus on Value — For Both the Enterprise and Individuals
- Understanding The Profitability of Accessibility
- Integrating Accessibility Into Design
- Integrating Accessibility Into Development
- Looking Ahead — Keeping Up With the Changing Legal Landscape
We covered 1–3 in part one of our series. We’ll now take a look at 4–6.
Integrating Accessibility Into the Core of Design and Development
When web accessibility falls by the wayside, the reasons depend on the department. For management, it is often financial constraints — the budget doesn’t allow for the additional work. For developers, it can be time constraints — learning new specifications or modifying code retroactively takes a dedicated chunk of effort away from other project needs. And for designers, it boils down to aesthetic constraints — imposed constraints on typeface, colour contrast, and use of images limits the options for what can be done.
While each excuse can technically be true, they all hinge on the assumption that accessibility is done at the end of a project. In part one, we established that it should be a consideration at the beginning, but even when it isn’t, implementing accessibility at the end of a project can still be profitable.
Here are some basic principles that should be part of standard design and development practice. These principles can help your web-experience grow into a beautiful, thoughtfully-coded, user-friendly environment — far more accessible and profitable than their non-accessible counterparts.
Design, UX, and Interaction
UX, interaction, and visual designers are the gatekeepers of information and communication. Their decisions dictate not just the journey a user takes through a website or product, but also how they feel when doing so.
Being the advocate for the user isn’t always easy. Before software even enters development, designers have a responsibility to lay accessibility groundwork for everyone, and they don’t have to sacrifice beautiful design in the process. What follows are a few practical basics for design. It is by no means comprehensive, but it’s a start.
Display global navigation:
Make sure your users know where they are at all times. Use a breadcrumb, perhaps, or some other indicator of location, and ensure that consistent structures and names are used throughout the site or product.
Convey information in multiple ways:
Colour and contrast are a huge part of a design’s aesthetic as well as its accessibility. Consider using multiple methods to convey information. Don’t use colour alone (especially for required fields in forms). A good level of contrast ensures that content can be distinguished from the background. In her ALA article, Jenn Lukas shows how easy it is to verify this, or integrate it into your design by running your site through a contrast check.
Unleash your inner typography nerd:
Make all text readable and resizable. Start with the right choice of alignment (left to right where applicable), an organized heading structure, and good line length. If you use icon fonts, provide a text equivalent. Also, be careful with light font weights as they can be difficult to read.
Make forms accessible:
Especially in enterprise software, there’s nothing more frustrating than trying to fill in a simple form and feeling completely blocked. Designing for accessibility starts with considering how we structure labels and their inputs. Consider drawing attention to both required fields and errors in an obvious way. See this article by WebAIM to get started.
Make sure links are recognizable:
Similar to conveying information, links shouldn’t only be differentiated by their colour. Add underlines or different text styles to ensure they’re always visible.
Be careful with animation and video:
When animation (any elements that move, blink, or flicker) is used, be aware that a user should be able to select a mode where animation is deactivated. If your animation is presenting meaningful or necessary content, make sure that thought and time is devoted to providing an accessible, non-animated alternative.
It can seem overwhelming at first, but none of these items should be challenging constraints for designers, or be a barrier to designing beautiful websites or applications. Accessibility guidelines give hints as to how to use colour, for example — they don’t tell the designer which colours to use, and there is a difference. If these guidelines are part of our considerations when we start a project, then there is no excuse for not including them, especially if a WCAG2.0 AA rating is just one hex code away.
What’s behind the scenes is just as important as the aesthetics and the smallest change to development workflow can have a huge usability impact. There are just as many (if not more) resources for developers as designers. With so many possibilities for accessibility solutions, simply taking the time to choose one (let alone implementing it) can be exhausting. Editing legacy code can be similarly painful, and can often feel like a chore if accessibility isn’t made part of a project’s beginnings. We suggest — as with design — starting small.
What follows are a few practical basics for code. Again, this is not a comprehensive list by any means, but it’s a start.
Use basic ARIA attributes and fallbacks:
ARIA (Accessible Rich Internet Applications) is one of the W3C’s specifications and gives support to users of assistive technology. ARIA attributes provide information about a web page’s various user interface elements and their roles, ensuring that assistive technology such as screen readers can understand the most important interface elements of the app. A full list of ARIA best practices can be found on the Web Accessibility site.
Utilize semantic structures:
This is important, both for IA and Accessibility. HTML5 offers semantic components such as <section>, <nav>, <header> and <footer> among others. Using these improves accessibility for all, as well as creating cleaner and more readable code in most cases. Caveat: some of these elements are new and support is coming. There is, however, existing support for <h1> to <h6> elements, as well as lists: <ul>, <ol>, and <dl>. Content should be organized logically and semantically using these elements. Websites will be more readable and usable for everyone.
Use alt text with images:
Not all people will access the app or site’s information on a screen, and therefore they may not see the images. Use the alt attribute or longdesc file to ensure an image has the appropriate description. Alt text is fine as a concise image replacement. If the image has meaningful content in it — charts, text, or something else which is integral to the content on the page — make sure that an extended text description is available in the longdesc file.
Ensure keyboard access:
Not everyone has a mouse with which to access the web. A user should be able to move through your content with only their keyboard, and in a logical order. This is one of the most important parts of web accessibility, and also one of the easiest to test.
Use focus indicators:
When navigating a page using only a keyboard, the user must always know where they are. Right now, there is a default outline provided by the browser — this can be kept in place, or some other stylistic element can be used.
Leverage WAVE and Other Tools That Help With Accessibility Testing:
No one tool is perfect, but there are many that can be used to test various parts of a website, provide quick audits, help prioritize issues, and provide solutions when needed.
- WAVE check is run by WebAIM, and provides an overview of a web page’s accessibility issues. It also has its own API. AccessLint and 508Checker provide similar services.
- Chrome’s Accessibility Developer Tools adds an accessibility audit, and a pane in the Elements tab of developer tools provides useful debug information on contrast values, missing ARIA attributes, and a good deal more.
- ChromeVox is a screen reader extension for Chrome, and can be used by anyone to test how their website or product fares on screen readers.
Developing an accessible website or piece of enterprise software need not become complicated if we start small, utilize guidelines and tools provided and build it into our process from the get go.
The first and most important caveat: we are all only human. Rome wasn’t built in a day and fixing web accessibility issues won’t happen in a day either. The options presented in this piece offer some easy, immediate wins. But they are just the first steps. Accessibility doesn’t end with alt text and running a URL through a testing tool.
For enterprises in particular, software infrastructure is massive and has many stakeholders. But this is not an excuse. It’s merely an indication that accessibility should be considered from the start, as carefully as possible.
Achieving the highest accessibility standard (WCAG 2.0 AAA) is hard — make no mistake — but there are many fringe benefits (SEO among them) that the enterprise or business can enjoy in addition to higher levels of employee/user engagement and satisfaction.
The first thing we can all do, no matter what group we belong to, is step out of our comfort zone and test our sites and applications ourselves. Karl Groves, an accessibility advocate & consultant, points out there is impact in even the smallest change. When given the right priority, accessibility need not compromise aesthetics, development, or finances.
The Landscape, Legal and Otherwise, is Changing
While it is illegal to discriminate against those with disabilities, the legislation around web accessibility is yet to catch up. Slowly but surely, though, countries around the world are starting to address the issue in the courts, not just at the screens.
Here in Ontario, all new public government websites must comply with WCAG (Web Content and Accessibility Guidelines) 2.0, the internationally-accepted web accessibility standard. By 2016, all government websites will have to comply. By 2021, all public websites and web content for government, public-sector organizations, businesses, and non-profits will have to conform with WCAG 2.0 AA — the second level of the three accessibility success criteria.
And this is just Canada’s recent legislation. In the United Kingdom, websites are considered one of the “services to the public” covered under 2010’s Equality Act, making it possible for individuals to take legal action against organizations with discriminatory websites. In Norway, accessibility is legally mandatory. And in the EU, all websites managed by public sector organizations must be accessible to everyone. There are more exhaustive lists — such as the one managed by the W3C here — that describe accessibility legislation in more detail, but it’s clear to see that worldwide the law is taking steps to enforce the accessible web.
There are now more resources than ever and a great deal of excellent writing being created regarding accessibility implementations and consequences. A few of note:
- On A List Apart, there are a variety of articles, both technical and philosophical.
- On the Pastry Box Project, Anne Gibson’s aforementioned alphabet of accessibility, in particular, highlights the futility of attempting to draw a line of ‘normality’ when it comes to web access.
- Marcy Sutton writes often on accessibility wins around the web.
- From a software creation standpoint, agency Ustwo have released their Pixel Precision Handbook 3, a handbook of their process which includes their accessibility approach.
- Dennis Lembree’s excellent WebAxe blog and podcast has been around since 2005, and provides a great deal of practical advice and resources.
We’ve included a list of additional resources for exploration at the end of this paper.
Are You Ready For The Future?
We’ve already started to hear from those who are seeking a more accessible web. And as the legal landscape changes, the discussion around accessibility will become more important.
We believe you can and should explore getting ahead of the curve. It starts with a change in mindset and a change in how we define accessibility, then continues with how you integrate it into your design and development process.
Accessibility on the web can be a win-win situation — both in profitability and from a social responsibility perspective. The question is, how then will you adapt and move forward into the future?
A few papers and tools that will help designers, developers, and managers alike get started with accessibility, and start breaking up those myths.
- http://wave.webaim.org/ — WebAIM’s WAVE Accessibility Checker.
- http://webaim.org/blog/10-easy-accessibility-tips/ — Also from WebAIM, a list of ten accessibility basics that everyone should know.
- http://webaim.org/resources/designers/ — The last resource from WebAIM, a simple infographic (and text alternative) for designers to refer to when designing for an accessible web.
- http://cameronmoll.com/downloads/Web_Accessibility_Checklist.pdf — An accessibility checklist created by Aaron Cannon, accessibility advocate and consultant.
- http://www.csd.uwo.ca/~markp/htmls/accessible.pdf — An excellent 2005 paper by Clare So, Mark Parry, and Stephen Watt of UWO, highlighting the ways a semantic web (now a necessity) improves accessibility.
- https://webaccessibility.withgoogle.com/course — For the academically-inclined, Google offer a self-driven Introduction to Web Accessibility course.
- https://github.com/paypal/bootstrap-accessibility-plugin — A very useful Bootstrap plugin which makes Bootstrap 3 elements accessible for keyboard navigation as well as screen reader users.
Additional Resources for Learning:
Here are some great places to start the accessibility reading journey:
- The Accessibility Project — How-tos, tests, tips, and a great community from which to draw resources, inspiration, and help.
- Accessibility Wins — An offshoot of the Accessibility Project; this tumblr showcases accessible user interfaces.
- Karl Groves’ Blog — Web accessibility consultant Karl Groves has a range of posts on the site, from technical to ideological — something for everyone, all of them brutally honest.
- Developing a Web Accessibility Business Case for Your Organization — An overview from the W3C on the factors of developing a business case.
- WebAIM — WebAIM’s (Web Accessibility In Mind) introduction to web accessibility. They also have a wealth of articles and resources for all levels.
- A List Apart: ‘Accessibility’ Archive — Always helpful, A List Apart offers articles varying from the basic to the psychological to the technical, something for everyone.
- WebAxe — Dennis Lembree’s excellent podcast and blog on accessibility, founded in September of 2005.
- 7 Things Every Designer Needs to Know About Accessibility — A list of seven items that each designer must know to ensure their work meets WCAG 2.0 guidelines.
- Web Accessibility: Best Practices — A comprehensive list of all web accessibility guidelines, technical and otherwise, and the intricacies of implementing them.
- A Systematic Approach to Making Web Applications Accessible — A blog post by Dr. Silvia Pfeiffer, detailing an example process for making accessible web apps.
- “It’s Alive!”: Apps that Feed Back Accessibly — An extract from Heydon Pickering’s book “Apps for All: Coding Accessible Web Applications,” published on Smashing Magazine, about using ARIA live regions.
If you or your company are writing about accessibility, be it wins or challenges or anything in between let us know — there can never be enough great writing out there.
Special thanks to co-author @IvanaMcConnell.
If you enjoyed this piece, or found any valuable resources, please scroll down and click the “recommend” button — we’d really appreciate it.