Published: 2021 > 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 technical details 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, education level and software they use 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)](https://www.w3.org/WAI/standards-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 in 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](https://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown) ### Accessibility principles The industry-standard guidelines for web content accessibility are organised around four principles: `Perceivable`, `Operable`, `Understandable`, and `Robust`. **P for perceivable** Information and user interface components must be presentable to users in ways they can perceive. Does your website work for people with low vision? What about a grayscale mode? **O for operable** User interface components and navigation must be operable. All core workflows are available from a keyboard? Users can use different input modalities beyond the keyboard? **U for understandable** Information and the operation of the user interface must be understandable. Is text readable and understandable? Users are helped to avoid and correct mistakes? How easy is not find support and documentation? **R for robust** 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. ## Grades > The WCAG 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2019.151.01.0070.01.ENG&toc=OJ:L:2019:151:TOC) **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 ## Baby steps **Determine the status of your project** The very first recommendation you can investigate and try is to integrate a simple audit tool, such as [axe](https://github.com/dequelabs/agnostic-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. In this case solutions like [video-based QA Session](https://makeitfable.com/tutorial/qa-sessions/) is a solid choice. Axe automated testing is 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 for your project to catch errors, you can even [integrate axe with Cypress](https://github.com/component-driven/cypress-axe) > 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. ### Checklists Checklists are not an ultimate solution, but they will help you. Curated by industry professionals it's a great way to start diving into specs and requirements in a friendly manner. **WCAG 2.1 quickref checklist** [http://www.w3.org/WAI/WCAG21/quickref/](http://www.w3.org/WAI/WCAG21/quickref/) **Deque Web Accessibility Checklist for Developers** [https://dequeuniversity.com/checklists/web](https://dequeuniversity.com/checklists/web/) **Deque Web Accessibility Checklist PDF for Developers** [https://media.dequeuniversity.com/public/en/docs/deque_web_accessibility_checklist.pdf](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](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. #accessibility #conversations