Accessibility is not only a technical challenge, but also a challenge for process management.
This means that organizations and projects must permanently integrate accessibility into the design, development, and testing process. This requires a team, expertise and commitment, as well as leadership.
Table of contents
1. Responsibility of Accessibility
2. Web Development Process
2.1 Planning / Designing Phase
2.2 Creating / Implementing Phase
2.3 Testing Phase
3. Take Accessibility Seriously
3.1 Time Management
In this article, I would like to point out some recommended steps to follow when implementing an ICT (Information Communication Technology) accessibility plan for an individual project or organization, which are very well described by the W3C Web Accessibility Initiative (WAI) in the Planning and Managing Web Accessibility section.
They also provide guidance for immediately removing accessibility barriers in existing websites in the section Web Accessibility First Aid: Approaches for Interim Repairs.
1. Responsibility of Accessibility
A few weeks ago, I was invited to a Q&A session about who is responsible for accessibility. All participants agreed that it takes a team to integrate accessibility into the project or more broadly into the organizational culture.
As a team, you should set accessibility implementation goals or adapt internal standards, best practices, and tools needed to integrate accessibility. It would also be useful to create accessibility guidelines, not just for a specific project, but for the entire organization.
Similar to the Scrum process, where a Scrum Master is responsible for ensuring that the Scrum team successfully implements the Scum framework and keeps obstacles at bay, it would be useful to have an accessibility expert on the team (or an external consultant) to support the team and ensure that all members are developing with accessibility in mind throughout the web development process.
2. Web Development Process
When defining a web development process in an agile workflow, the process starts with planning the product, followed by the actual creation of the product, and the last thing is to test it properly.
This cycle is repeated for each task until the task can be considered done. Let's take a closer look at each step of the web development process.
2.1 Planning / Designing Phase
When designing a product, accessibility must be considered from the beginning. So when doing your research, make sure that people with disabilities will also use your product.
When it comes to setting requirements, define not only marketing and sales goals, but also accessibility goals, such as accessibility standards and best practices.
Most of the implementation of accessibility into the process can be done in the design of the information architecture and user experience. Be aware of what to think about when designing a product with accessibility in mind.
Here are some examples of what should be part of the information architecture:
Designing for desktop and mobile
Interactions are very different. On desktop, users mostly use the mouse and/or keyboard, while on mobile they use a touchscreen and type and wipe with one, two or three fingers. Screen reader compatibility on the desktop is different from mobile screen reader compatibility. Decide which browsers to support.
Designing for sighted and blind keyboard users
Sighted keyboard users need full keyboard functionality and a visual focus indicator. They must be able to jump directly to the main content by skipping the navigation menu. Dynamic widgets must be fully operable (to prevent keyboard sticking).
Proper semantic markup must be provided for blind users. The DOM structure should be divided into landmarks, using a proper heading structure.
Content creators may already provide alternative text for images. They also create the content so that it is understandable to any user.
Custom widgets are created with ARIA markup to be compatible with screen readers.
Designing for users with visual impairments such as low vision or color blindness
It would be best to already have a design system and prototypes of the product using a design tool such as Figma or Adobe XD where the file structure can be visualized, colors with sufficient contrast that are never used alone to convey information, and accessible typography are established.
Components should be properly designed and prototypes delivered for desktop, tablet, mobile, and at up to 400% magnification.
Designing for Users with Hearing Impairments
Visual designers should create prototypes for videos and audios that include video captions and transcripts.
Designing for users with cognitive disabilities
Content creators need to provide alternative text for images, taking into account best practices, such as not writing text longer than 150 characters, as some screen readers do not read the entire text and stop suddenly. Also, users cannot pause the screen reader on alt text.
Content writers also need to create content that is understandable to any user and keep sentences short and simple.
2.2 Creating / Implementing Phase
When there are clear instructions from the previous planning phase, it's much easier for web developers to create these components and make them accessible. They no longer have to think about how to design the components, what color or font to use, and can start coding.
Something that would really help to work with tested components and stay consistent with the code and guarantee code quality would be a component library created with Storybook or Pattern Lab, for example.
Developers who have a high level of knowledge of how to write accessible code can create components and test them before implementing them.
Another advantage of a component library would be that new developers who come into the project later, or developers who are not as familiar with accessibility, can look at any component in the library and just copy it and use it immediately without worrying about it.
Creating Components
When creating components, the developer must be sure to use proper semantic HTML (compatibility with certain browsers) to structure the layout (landmarks), add alt text to all embedded images, and follow the logical reading order.
The developer must understand that the DOM tree is the actual reading order that a screen reader follows, and should be able to use CSS styles correctly and know the advantages and disadvantages of some attributes.
When creating custom components and widgets, the developer must be careful to use the correct ARIA markup.
2.3 Testing Phase
When it comes to testing, it is important that the Q&A tester knows how to test for accessibility and when the requirements are met.
Testing the frontend markup
The first step would be to use automated testing (if not already integrated into the development process) with tools like axe. 30% of issues can already be fixed this way.
The main part of testing is still done manually. So using the website and its widgets only with keyboard or screen reader has to be done and tested independently by the tester.
This of course includes cross-browser testing and different combinations of browsers and screen readers, because each screen reader behaves differently depending on the browser.
Reviewers should know that even if all components and widgets pass accessibility testing, this does not necessarily mean that they are fully accessible when used together on a web page.
Therefore, additional testing must be performed when a page is created. In addition, testers must ensure logical reading order, heading hierarchy for sections and content, and comprehensibility.
If problems occur, testers are responsible for describing defects with detailed accessibility user stories, instructions for reproducing errors and images, acceptance criteria, etc.
3. Take Accessibility Seriously
If accessibility is taken seriously from the start, chances are good that users' needs will be met. Otherwise, it is almost guaranteed that the website will have accessibility issues that prevent users with disabilities from using the website properly.
In this case, retrofitting comes into play. And I am certain we all have no interest in playing that game.
You should always ask yourself:
Would it be better to fix the old design, or would it be better to start fresh and create a new design the right way, with embedded accessibility?
3.1 Time Management
Companies are often concerned about how much extra time accessibility takes. If implemented properly from the beginning as described, accessibility tasks add a maximum of 5% to the overall development time, which in my opinion is perfectly acceptable in contrast to double or triple the time (and cost) if accessibility is added at the end of the development process or much later.
Thanks for your reading and time. I really appreciate it!
Top comments (0)