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
• Legislation
• First steps

The definition

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

Accessibility principles

👩🏻‍🚀 The industry-standard guidelines for web content accessibility are organised around four principles: Perceivable, Operable, Understandable, and Robust.

P
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?

O
User interface components and navigation must be operable.
💡 Functionality is available from a keyboard? Users can use different input modalities beyond the keyboard?

U
Information and the operation of the user interface must be understandable.
💡 Text is readable and understandable? Users are helped to avoid and correct mistakes?

R
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
assistive technologies.

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

Wrapping up

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 👇