All users should have a rich and complete user experience when browsing your website, regardless of how and what they use to browse. Yet, that's not always the case.
Making accessible websites is one of most important - and often overlooked - accountabilities of front-end developers.
What makes me personally really excited about front-end development is our impact on achieving the above. Every single choice we make when programming a website has an impact on its accessibility. It will - or not - grant access to content for everyone. We truly are responsible for preserving the most important premise of the internet: Making information and entertainment available to all people.
At Netcentric, our front-end development team has a real commitment to accessibility. We follow the Web Content Accessibility Guidelines (WCAG 2.0) in all of our projects. We also make sure to be up to date with the latest Web Accessibility Initiative (WAI) recommendations when designing implementations for our clients.
Like everything front-end related, both WCAG 2.0 and WAI are in continuous development. So, too, are our plans to meet a minimum level of conformance for all websites we produce. We also ensure our expert team keeps up to date with evolving standards so that we are able to assess, determine, and provide solutions to accessibility issues for all our marketing and web applications.
But what is website accessibility?
Making a website accessible means developing it in conformance to the latest standards defined by the W3C community. Accessibility encompasses a variety of features ranging from clear visual indication of every element (especially call to action elements, such as buttons or links), to enabling the proper use of assistive technologies such as screenreaders in the page, to facilitating keyboard only navigation.
For the most part, it means supporting assistive technologies that many users with disabilities must rely on, such as screen readers or keyboard navigation. It means considering people with mobility disabilities when implementing animations and effects. It means understanding the needs of ageing users. It means taking into account those users with sight impairments when setting the color contrasts and the way the interface responds to zooming. It means remembering that a flash of light can trigger a seizure in a photosensitive user and that a transcript is the only way for some users to understand audio content. But those are also some examples.
Web accessibility is not only about making it easier for users with disabilities. It’s about designing and developing for inclusion: embracing the ever growing diversity of devices and people connected to the internet, reaching broader audiences, and ensuring much larger conversion rates. It also means meeting the ever-growing legal requirements set by governments in order to make the web more accessible. It means covering your website for all possible ways a user might want to browse your website in a non-standard, with the mouse or fingertips, way.
Accessibility is not only about ARIA and its special attributes, it’s also about delivering in a responsive and responsible way; it’s about writing clean semantic and well structured HTML markup. It’s about using the right elements in the right places. It’s about captioning and providing alternatives. And it’s about working together with everyone involved in the production of fully accessible applications: designers, developers, content authors, and specifications analysts to achieve the same goal.
Coding for accessibility - what you should consider
Building accessible web applications can turn into a long process if you don’t have accessibility in mind from day one. There are some measures you can take to make it a bit easier and smoother.
Whether you are the designer or you get your design from an agency: take some time to review it and spot some of the most common accessibility issues. Inadequate colour contrast between background and foreground, a poor hierarchical structure, incorrect use of headings, generic call to action buttons, and small active areas are just a few of many issues to watch out for.
Assess the navigation. That’s one of the places where the most accessibility issues concentrate. If it is extremely complex and makes use of a lot of animations and effects, think of alternatives for users who may have a hard time accessing internal links in your website.
Design and develop mobile first.
The accessibility strategy should be designed according to the required level of conformance. Level A has the lowest standards, level AAA the highest. A good place to start for all levels is to make sure your HTML is valid as well as hierarchical and semantically correct.
For level AA and above, you will need to make your front-end implementation as clear and intuitive as possible, and users must be able to understand the immediate effects after clicking on links or buttons. Visual and audio information of the action they are about to make must be included. Good to know: Some governments require level AA by law.
Remember to provide alternatives. Identify non-text content such as images and audiovisual media and translate them into readable words for AT users. Ask for a definitive list of supported browsers and mobiles, and test for cross compatibility as often as possible, as you make progress.
Develop animations and transitions with empathy in mind. Give the users enough time to understand what’s going on. Make sure it’s always the user who makes transitions happen (like closing flyouts and popups).
- This should be specially considered when developing forms, as they require user input and interaction.
Help on the internet
Here are some useful tools that can help you in the process, apart from the official documentation:
For colour contrast ratios, these websites provide useful feedback:
The W3C gives some advice on how to implement forms here:
For ARIA attributes and explanation, follow these links:
There is also an official checklist you may refer to, by following this link: