Today, we are highlighting accessibility—something we strive to think about every day here at Envato Tuts+. December 3 is International Day of Disabled Persons. Created by the United Nations in 1992, this day seeks to promote the rights and well-being of persons with disabilities in all spheres of society. More than one billion people worldwide live with some form of disability.
In the context of web and app development, the goal of accessibility is that your tool works for all people, regardless of the hardware or software they are using, and wherever they fall on the spectrum of hearing, movement, visual, and cognitive ability. With rapid changes in digital and assistive technology, meeting this goal requires thought, testing, and an overall understanding of the way online tools are used by different people with diverse needs.
There are tools here at Envato Tuts+ and across the web that can help you learn how to design and code for accessibility, and I will link to some in this article. But in this post, I would like to look at the role of developers in web accessibility, and talk about why the best time to think about accessibility is at the beginning of a project. I'll also introduce some emerging issues around developing for accessibility, and raise considerations around barriers to access and advocate for the importance of engaging with users at different stages of the development process.
Thinking About Barriers to Access
The UN’s Convention on the Rights of Persons with Disabilities points out that the existence of barriers is a central feature of disability—that disability is an evolving relationship between people with impairments and the social and environment barriers with which they interact. Barriers are in themselves disabling, and exclusion is a structural problem that lives in our systems, rather than in the bodies of those with impairments. Because of this, removing barriers is a prerequisite to social inclusion for all people.
Let's think a bit about accommodations and barriers to access.
Last week, a friend pointed out that light bulbs are an assistive device for people who rely on their vision to get around. Using light bulbs in a building is a way to mitigate this barrier, since sighted people need light to navigate the world, but people without sight do not need this accommodation, as they navigate using other strategies. What we consider a “normal” accommodation is socially conditioned, rather than an objective truth.
I bring up this example to disrupt the idea of “normal”, and move away from thinking of accessible design as a special accommodation. If we prioritize making our technology barrier-free, rather than thinking about accessibility as an exception or afterthought, we can shift the concept of “normal” to accommodate all people and exclude none.
The strength of web technology is that, by its nature, it removes barriers that exist in the physical world. When building web and mobile app technology, it is vital that we are not add barriers back in to the technology through the way we design our tools. In order to do this, we have to to understand how different people use our tools, and what their needs are. And just like when considering whether to build a ramp or a set of stairs, the best time to think about this is before we start building.
Accessibility—Getting Started
When it comes to building accessible web tools, there are two main considerations: take advantage of existing accessibility infrastructure, and stay out of the way of assistive devices and other accessibility strategies.
Using alt text for all non-text elements (images, graphs, charts, etc.) is an example of how you can take advantage of existing infrastructure. Screen readers rely on alt text to parse a web content for visitors with visual impairments. This is not a complicated fix—alt text is simply good design. By designing for accessibility, you will improve the functionality of your website. In this case, search engines rely on alt text to better “read” websites. According to the W3, case studies show that accessible websites have better search results and increased audience reach.
Ensuring that keyboard input works with your tool is an example of staying out of the way of users’ accessibility strategies. Using a mouse requires a degree of fine motor control that many people do not have, and so they rely on keyboard input to navigate websites and apps. If your web tool can be navigated with keyboard input, it also allows assistive technologies that mimic the keyboard, such as speech input, to function properly. If you are build a tool that cannot be navigated with keyboard input, you are unnecessarily creating an inaccessible environment for users.
Knowing how different people interact with your web tool gives you the ability to make choices that support their accessibility strategies. It is so much better to do this at the beginning of a project than try to address accessibility as an afterthought. An illustrative example: UC Berkeley ran into trouble when they made thousands of uncaptioned videos—inaccessible to people with hearing impairments—available online. The university was legally required to caption the content, but did not want to pay for the expensive project, and eventually cancelled the project outright.
By making websites more accessible, you make your web tools work better, more of the time, for more people. The power you have as a developer allows you to address accessibility issues at the earliest stages, when it is the easiest and least expensive time to do so.
Tools and Guides on Accessibility
Here at Envato Tuts+, we have a variety of information on how to build better, more accessible, web tools. Here are a few to get you started.
.png)
AccessibilitySite Accessibility: Getting Started With ARIA
ARIA (the Accessible Rich Internet Applications Suite) is a tool to make web content and apps more accessible, especially people who use screen readers or cannot use a mouse. The main purpose of ARIA is to allow for advanced semantic structure within HTML as a counterpart to HTML’s syntax-heavy nature. In other words, HTML tells the browser where things go, and ARIA tells it how they interact. In this series, you'll learn how to use ARIA to make your web apps more accessible.
AccessibilityKeyboard Accessibility Tips Using HTML and CSS
In this post, you'll learn some tips to make your web page more keyboard accessible, using only basic HTML and CSS.
AccessibilityHow to Make Custom Accessible Checkboxes and Radio Buttons
It's important to make sure your checkboxes and radio buttons remain accessible to assistive technology (AT) and keyboard users. In this post, you'll learn how to make sure your custom checkboxes and radio buttons are accessible.
Complete Learning Guide to Web Accessibility
This is a collection of tutorials, articles, courses, and quick tips to walk you through the basics of accessibility.
I encourage you to also check out some source guides on accessibility from the W3. The W3 article on accessibility principles is a good place to start. They also have an article about strategies internet users can employ to make the web more accessible—this will get you started thinking about how different people have different accessibility needs, and how you can code to support accessibility for everyone. And this artlce goes over ways to optimize your computer for more accessible web browsing, which will give you an idea of some of the strategies people employ to make the internet more accessible for themselves.
User Testing is Everything
You’ve thought about accessibility. You are committed to removing barriers to access in your web and mobile apps. You’ve built a tool with up-to-date accessibility guidelines in mind. Is your app accessible?
There are guides on Tools and Tips for Testing for Accessibility, and that is an important part of the design process. Reading the guide and testing your web tool is a great idea. But go further: the gold standard in designing for accessibility is user testing. Involve users early in your project and throughout the development process.
Some accessibility requirements are easy to meet, and some are more challenging. Understanding how different people use your tools will give you so much insight into how to build for accessibility. Everyone has different needs, different browsers, different assistive devices. No guide or checklist is going to be able to fully capture the breadth of experience of the people using your tool.
Like learning that users are receiving error reports or a 404 page, be grateful if and when you receive feedback that your tool is not currently meeting a user’s accessibility needs. Solicit this kind of feedback. Keep an open dialog with users and find solutions to the issues they bring to your attention. Anything you build will evolve—nothing is static in web and mobile technology. The real-life experience of your users is the most valuable input you can receive, so if you hear something is not working, say thank you. And then find a way to make it work.
Conclusion
Thank you for spending some time with me on this International Day of Disabled Persons. My intention with this article is to create support the dialog around web and mobile accessibility, and to give you a starting off point for your own thoughts, research, and testing. Whether you are just getting started with programming, or are an experienced programmer, it is so vital that you are prioritizing accessibility in your development projects, so that your tools can work well for each person who uses them.
No comments:
Post a Comment