Web accessibility is an increasingly important component of web development, for usability, compliance and many other reasons. In this series we'll explore the topic in depth.
Introduction
In the process of implementing accessibility compliance (Section 508, WCAG 2.0 and WAI-ARIA) for KendoReact, our suite of native UI components for React, we learned a lot on the topic. With this blog series, our goal is to introduce fellow engineers to web accessibility and share our practical knowledge and best practices.
This first article is an attempt to answer what accessibility is and why it matters.
The W3C definition is a great starting point: accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the Web, and contribute to the Web.
The perfect example for accessibility is if you can use your site without looking at it. Instead, you would listen to a screen reader that describes the UI and navigate with keyboard only.
Why Accessibility is Generally Neglected
While there are many reasons why accessibility is not omnipresent, as it ideally should be, three of them seem to be key. First, it’s hard to accommodate for something that you don’t understand well. Second, making your application accessible requires a lot of work – from understanding the premises of the standards you need to follow to designing the needed features and functionalities into your app (or finding a good way to modify it if it’s a legacy project). Then of course, there’s testing whether your approach has yielded the desired result – and much of the testing can only be done manually. The practices described in this series will make this effort easier, but we are still talking about a serious undertaking.
Third is the economic argument which rightly or not dominates modern decision making: in most cases, a smaller percentage of your clients (or users) would be affected by a disability, which serves as justification to postpone implementing those accessibility improvements for the next release.
Why Accessibility is Important
Ethics
People with disabilities deal with a lot of challenges on a daily basis. If they are among your clients or users, enabling them to interact with your web app is plain human decency.
Market
There's data that one billion people worldwide, and 20% of all internet users, have some form of disability. This is still a minority, but it comprises of a lot more people than most of us would think.
Legal
As legislation in this domain develops, it becomes more and more likely for your business to be required by law to be accessible. The next section focuses on this topic.
User Experience
Accessibility guidelines are designed to help people access and use your website more easily. As a side effect, most of them improve usability and directly benefit all users, including those without disabilities. For example, readable text helps not only people with poor sight, but all users.
Engineering
Many of the good practices for accessibility are good engineering and design principles in general. Often it is the poorly written code that is not accessible. For those of us who strive for mastery of our craft, accessibility is just a matter of doing a good job.
Reputation
Having a more accessible site than your competition is a competitive advantage and can potentially create positive buzz around your brand.
SEO
There is some overlap between good practices for SEO and web accessibility. For example, writing semantic HTML with proper use of descriptive attributes such as labels, video transcription, image captioning and using title and header tags all improve both a website’s SEO and its accessibility.
Legislation
Current legislation is moving in a direction where accessibility is becoming a mandatory feature of the web. In the USA, accessibility is covered by the Americans with Disabilities Act (ADA). Many of the developed countries have similar laws, for example, the UK has the Equality Act of 2010. In practical terms, these laws mean that public sector organizations and businesses are required by law to follow the Web Content Accessibility Guidelines (WCAG).
It’s not just your customers and users you should be thinking about. If your organization has 50 or more employees, you need to accommodate those that have disabilities. This means your internal web tools will have to be accessible as well.
If you are a contractor working for the government, you need to comply with Section 508 of the Rehabilitation Act in your work in addition to the above. By law, all US government services need to follow Section 508.
These laws are not just an indication of good intentions. More and more law firms take legal actions based on accessibility legislation.
Conclusion
We hope you are convinced that accessibility matters and is a worthwhile project to pursue. Now that we’ve laid the foundations, in the following parts, we will explore how to achieve good results meeting accessibility requirements with a reasonable investment of effort.
The Whole Series: What's to Come
- Part 2: Types of Disabilities and Best Practices to Accommodate for Them. Here we further define the problem, break it down into sections on different disability types, suggesting individual solutions.
- Part 3: Technical Best Practices. This part is technically oriented and focuses on working with screen readers.
- Part 4: More Best Practices and Resources. Here we go over more practices about organizing our workflow and further explore how to make this daunting task manageable.
Oldest comments (1)
A question about the accessibility of "telerik.com/kendo-react-ui/compone...".
The menu is not navigable without screen reader - cannot control it with keyboard, but NVDA provides it's own way of navigating lists. I am not sure how big of a problem that is, but there are people who will prefer to navigate the page without the use of mouse, but don't have any screen reader installed on their computers. An example of such person can be somebody who is not visually impaired but have a motor impairment instead.
The second problem is about the "drop-down items" in navigation. Screen reader announces the "drop-down item" as "link". I don't think it's clear enough because most people would expect that a "link" navigates to a new page instead of revealing a list of items. I think that marking each menu item with role of "menuitem" and giving it "aria-haspopup" property would be more suitable, alternatively you could convert these items to buttons with "aria-expanded".