Introduction
Accessibility is something that is commonly misunderstood and even more commonly overlooked due to its perceived complexity or its perceived unimportance.
Throughout this series we will see that accessibility helps all of us, as we solve problems that face everyday users. The simplicity of implementation and the benefit for all users is what I hope to show through my articles in the coming weeks.
I personally believe that by the end of 2018 and through 2019, we will see a real change in the mindset of a majority of designers, developers and companies alike to push for a more accessible web and to put an accessible mindset on a majority of integrations and feature sets.
What will we cover throughout the series
Accessibility in and of itself is a build up of topics which we will cover in later in this series. These will be separated into a specification article, a design article, a development article and a testing and QA article but lets roughly go over what we will cover down the line.
WAI-ARIA and WCAG
WAI-ARIA
WAI-ARIA is short for: Web Accessibility Initiative for Accessible Rich Internet Applications.
The general idea of WAI-ARIA, often shortened to just ARIA, is to provide us as developers a set of helpers to increase the accessibility of our sites and applications, it is best if used with sites or applications generating dynamic or changing content.
"WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities." - WAI-ARIA Overview
WCAG
WCAG is short for Web Content Accessibility Guidelines.
As the name suggests, its primary focus is on page content including but not limited to: text, images, forms, audio and video.
"Web Content Accessibility Guidelines (WCAG) is developed through the W3C process in cooperation with individuals and organisations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organisations, and governments internationally..." - WCAG Overview
Indeed, it fulfils this purpose well and this specification is used as the basis for accessibility laws in countries, albeit versions of the specification use can differ.
For reference, here is a useful article on the use of WCAG as a basis in law for countries around the world: Countries that Have Adopted WCAG Standards
Design
What is designed will likely, after some iterations, be implemented and so it is important that topics from UX to Accessibility are considered throughout the design process from concept to user journey and back again.
Colour contrast, font sizing, interaction area and animation are merely a subset of considerations for designers when it comes to accessibility. Once you start looking into these things in detail and integrate an accessible mindset into your workflows, the first line will have done its job and guaranteed a base layer of inclusivity for the next line to pick up from.
Development
The code we write as developers has a massive impact on every single user who accesses our product, service or platform.
We have a huge responsibility to ensure performant, reliable and robust code on a daily basis. As the industry continually shifts and things get more hectic, it is easy to overlook certain topics or to think them too difficult or time consuming to be of value but this is a fallacy. Semantic Markup, WAI-ARIA and WCAG are among some of the things in our tool belt to provide accessible experiences.
All of these will be covered in future articles in the series. Hopefully after that initial hurdle of conceptualisation, you will see how easy it is to improve and implement accessibility on the development side. In this section we will also build out some common components and show how we can improve upon them to make them more accessible.
Testing and QA
The next area we will look at is QA. If you don't have someone or better yet a team taking care of this in your team, it will fall on the CI/CD and testing processes.
Automated accessibility tests can only pick up 20% - 50% of issues however and so on top of CI/CD, a thorough testing of our feature implementations is required in tandem. This includes testing in as many ways as possible, external user testing for example and so it is important to reinforce this before code ships to production.
After we have designed and developed some components, we will write some accessibility tests and implement them in a simple test suite.
Why should we care?
Well, this can be answered in one of 2 ways when it boils down to it.
Firstly and primarily the main reason is that it's the right thing to do. Everyone deserves the fulfilment of the original promise of the internet: A free and open place to share, interact with and consume information without discrimination or bias.
"The power of the Web is in its universality.Access by everyone regardless of disability is an essential aspect." - Tim Berners-Lee
If that isn't enough reason for you, there is the second point of the law to consider. In almost all countries there is a law in place that will cover the topic of accessibility in some form or another. For reference, the UK has one that covers all government, public and private institutions whereas Germany has 2 laws, one for public and private businesses and another for government institutions.
Generally you will find that most countries follow the WCAG 2.0 specification and implement their laws based on this. For this reason, we will be covering WCAG 2.0 and WAI-ARIA in the next article as a foundation for moving into the design, development and QA followup articles.
In conclusion
I hope this has been a nice general overview of what accessibility generally is and what we will aim to cover in the upcoming articles. Together we can all make a difference from every level and make a difference for all. See you in the next one.
Top comments (2)
Great intro, and I'm looking forward to reading the rest of it!
One little bit of feedback - WAI is the Web Accessibility Initiative, not World :)
Thanks for the feedback, I updated the line in question. Much appreciated!