Web accessibility is about making web content available to users with disabilities. Development teams can use the success criteria of the Web Content Accessibility Guidelines to improve accessibility and create an inclusive website.
Joanna Falkowska gave a talk about creating accessible websites at DEV: Challenge Accepted.
There are different kinds of disabilities, Falkowska said. Think of users with sensory limitations (e.g. visual, hearing), physical ones (e.g. missing limbs), neurological diseases (e.g. Parkinson’s disease), or cognitive disability (e.g. Down syndrome).
The WHO estimates that about 16% of the world’s population is affected by significant disability:
If we add all of the mild ones, as well as groups that usually do not consider themselves disabled but might be facing similar problems, such as the elderly, the number becomes even higher.
Falkowska mentioned that development teams who do not know where to start their accessibility journey may feel overwhelmed by the number of disabilities they should take into consideration. They may have no idea about the limitations different users with disabilities face when opening their web app:
What they need is a benchmark that gives them clear criteria as to what makes an app accessible.
The Web Content Accessibility Guidelines (WCAG) is a document that serves people who create web apps. It has been drafted to make the web accessible and it gets updated every now and then to keep up with the development of the technology people use, Falkowska said. Just as the offline world can be more or less friendly for people with disabilities, the same way the websites that we browse can be more or less accessible, she added.
The WCAG gives you a set of success criteria that have assigned conformance levels, as Falkowska explained:
The lowest and the most basic one is A. The Web Accessibility Initiative (WAI), who is responsible for drafting and updating WCAG, states that any website we browse should address at least this level of conformance.
AA is a bit more complex, but at the same time it is the level that the authors (and many legal acts) recommend to follow, Falkowska said. The third and generally the most difficult to achieve is AAA. Usually the entities that address triple A will either be governmental/federal offices or companies/associations that serve specific groups of people with disabilities, Falkowska mentioned.
The levels are a bit like the wooden nesting doll "matryoshka", Falkowska said; if you want to address AAA with your website, you also need to cover AA as well as A’s success criteria.
Falkowska mentioned that one of the most commonly missing success criteria tells you to add alternative text to any content that makes sense only if you can perceive it with your eyes. For example, if your website contains an image, a person who cannot see and uses a screen reader will only hear the name of the file, which may just be a meaningless string of numbers and characters. In order to make sure they can perceive this content in a meaningful way, developers add an "alt" attribute in html, Falkowska said. The content of this attribute will not be visible on the website, but the screen reader will read it to a person using assistive technology.
InfoQ interviewed Joanna Falkowska about the success criteria for an accessible website.
InfoQ: Can you give some examples of success criteria?
Joanna Falkowska: An example would be keyboard focus. It should be possible for the user to navigate all of the interactive elements with a keyboard, which is achieved with the "tabindex" attribute in html. It is beneficial not only for users with visual disabilities, but also to those who cannot use a mouse due to hand tremors, e.g. because of Parkinson’s disease. It is also a very good example of how a success criterion may support users without disability. I cannot count the number of situations when my mouse was discharged and I needed to navigate the web with a keyboard only while waiting for the mouse battery to fill up...
Another example is that of screen orientation (which is mainly important for tablets and smartphones). It should not be limited to landscape or portrait-only mode. Some users may use a mobile device in one orientation only. Think of the users with quadriplegia who have their phone attached to a special handle or a tripod. They cannot move their phone around. We should not lock their display to one specific orientation with the CSS rotate and/or transform property.
One of the newest success criteria discusses authentication issues the users may have. Authentication should not strain short-term memory with puzzles, so we need to make sure that our login feature allows for copy-paste and/or the use of a password manager. Make sure your input fields provide proper "label", "type" and "autocomplete" html attributes. Apart from that, we should no longer require the users to solve the CAPTCHa in which the content needs to be deciphered and then typed into an input field. Object recognition is still allowed at AA level, but if you wish to succeed with AAA, even this type of CAPTCHa should be removed.