Many times, I've tried to find a comprehensive, yet, not too detailed technical first-temps guide to accessibility for the team. So I decided to put together this one. For anyone who would want to step outside their daily coding tasks for a breath of fresh a11y air.
This article might be helpful for answer some common questions, leaving coding aside, such as:
- Who is responsible for accessibility?
- Who defines web accessibility?
- Common principles
- First steps
At the most basic level, accessibility ensures that everyone, regardless of ability or disability, can access your website or application.
The definition is more nuanced than that, though. The Web is fundamentally designed
to work for all people. However, poorly designed and inaccessible applications lead to broad-scale exclusion.
Who defines web accessibility?
👉 World Wide Web Consortium (W3C) - Web Content Accessibility Guidelines (WCAG)
💡 It’s important to note that the WCAG standards themselves are guidelines, not law. The W3C itself evaluates organisations based on these standards but doesn’t have the authority to enforce them.
The Web Content Accessibility Guidelines (WCAG) 2.1 is a comprehensive standard for web accessibility. It is also currently the basis for legislation on web accessibility in many parts of the world. In Europe, the guidelines are referenced in the standard EN 301 549 Accessibility requirements for ICT products and services, which is the basis for EU legislation on web accessibility.
Who is responsible for accessibility within the team?
To keep the commitment active, and most importantly, to translate it into action, all team members need to know how they should contribute in their own specific role. This is not limited to the roles working directly in web production, such as design, development, authoring, engineering, and testing practices.
Having said that accessibility is a team afford, it should be integrated into design process and product definition, from the start. Developers has to do out best to advocate for it and know the tools, but, luckily they are not on their own.
👉 Accessibility responsibility by roles:
Accessibility Responsibility Breakdown
👩🏻🚀 The industry-standard guidelines for web content accessibility are organised around four principles:
Information and user interface components must be presentable to users in ways they can perceive.
💡 Does your website work for people with low vision? Or in a grayscale mode?
User interface components and navigation must be operable.
💡 Functionality is available from a keyboard? Users can use different input modalities beyond the keyboard?
Information and the operation of the user interface must be understandable.
💡 Text is readable and understandable? Users are helped to avoid and correct mistakes?
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. 💡
Robust content is compatible with different browsers and
The guidelines include three levels of success criteria to be met when testing. These levels are denoted with A, AA, and AAA, with AAA being the highest level of conformance and A being the lowest, while still conforming.
🧑⚖️ Legislation (Europe)
Within the EU, the enforcement of the Web Accessibility Directive is currently the foremost factor driving demand for web accessibility knowledge and services in the public sector. With the upcoming European Accessibility Act, there will also be new legal imperatives on the private sector within the next few years.
The enforcement of the Web Accessibility Directive is based on monitoring, self-declaration, and the possibility for end-users to complain. If the organisation covered by the directive doesn’t fulfil its obligation, it can be fined.
European Accessibility Act
The European Accessibility Act (Directive (EU) 2019/882), is a directive that will enter into force in the member states by 2022. The act covers the private sector and focus on certain accessible products and services that have been identified as being most important for persons with disabilities.
European Union (2019). European Accessibility Act. Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services.
EUR-Lex - 32019L0882 - EN - EUR-Lex
The European standard for ICT accessibility: EN301549
The European standard “EN301549 v.2.1.2 Accessibility requirements for ICT products and services” acts as the presumed conformance to the minimum requirements of the Web Accessibility Directive.
Annex B covers the relationship between the functional performance statements and the technical requirements, and can be used to support the reader in understanding what
noncompliance may mean to different user groups.
When it comes to the technical requirements for web accessibility, the EN301549 is
referring to the international standard WCAG 2.1 AA.
There is a wide range of disabilities, but accessibility aims to make sure that people can use the web no matter their abilities. It is important to consider and design for different types of use cases, as listed in the EN301549.
- Usage without vision
- Usage with limited vision
- Usage without perception of color
- Usage without hearing
- Usage with limited hearing
- Usage without the vocal capability
- Usage without manipulation or strength
- Usage with limited reach
- Minimise photosensitive seizure triggers
- Usage with limited cognition
Very first steps as a developer
Status of your project 🥽
The very first recommendation you can investigate and try is to integrate a simple audit tool, such as axe for the DOM for potential accessibility issues, just to see where you are and how you feel. Manual testing can be hard at first, as you don't know what are you testing. It's an integration in the development environment and should be pretty straightforward, it gives helpful hints in the console while developing features.
If you’re setting up automated tests (and you probably should), you can even integrate axe with Cypress
👩🏻🚀 There is only so much that can be automated. Auditing the HTML and CSS for potential pitfalls is a good place to start, but ultimately it is not going to replace some careful manual testing.
Grab some checklists ✅
WCAG 2.1 quickref checklist 👉 http://www.w3.org/WAI/WCAG21/quickref/
Deque Web Accessibility Checklist for Developers 👉https://dequeuniversity.com/checklists/web
Deque Web Accessibility Checklist PDF for Developers 👉 https://media.dequeuniversity.com/public/en/docs/deque_web_accessibility_checklist.pdf
Deque Basic Web Accessibility Checklist for Designers 👉 https://dequeuniversity.com/assets/pdf/module-design/dq-designers-checklist.pdf
Remember that this introduction is the starting point for an accessible design and web, not the endpoint.
Knowing the tools and being able to explain the importance of the work we do clearly makes a difference and if you just come to a11y community, I hope you stay 🙃
If you like this article and the information that I have put together, please, share it with your colleague and reach out to me on Twitter, whether you liked it or have suggestions 💚
Stay with me on twitter 👇
Alena Nikolaeva 🌸@alenanik11Thanks, @lifeofablindgrl for inspiring me to write my first article on accessibility.
I decided to put together what I have learned so far about modals and small changes that help others ☺️
dev.to/alenanik/inclu…19:23 PM - 19 Jan 2021
Top comments (4)
Loved the write up Alena! Some other tools we use at Forem for component tests are jest-axe and Preact Testing Library, and for Cypress we also use Cypress Testing Library.
More about all that in our frontend testing documentation:
Looking forward to your next post!
I think the next one would be about Cypress, I was surprised that you can configure different conformance levels and even customise some rules. Looking forward to exploring on that a bit more and write down some ideas ☺️
My only criticism (if you can call it that) is that it ended just a little too early, I got to the first steps part and then felt you missed one line to say "now look at all of the problems that the automated tools give and try and work out how to fix them."
Essentially I am complaining that I was enjoying the article that much I wanted more 😋🤣
I look forward to the next article you do on accessibility! ❤🦄 (is there another "inclusive components" article in the pipe line?)
Thank you 😄
Testing and analizing the problems before fixing is such a complex topic! I think what you can essentially do with the output is share it with the team, design and stakeholders and think what eventually can be done (estimate, iterate on next dev cycle, explore options with designers to get accessible color pallets (if that's the issue), or... education?), many options here 🤔 But definetly, we can't stop here 🚹
Bear with me untill the next one and thanks for stopping by 💖