Under Discussion: The Current State of Web Accessibility

At the December 2019 edition of dotCSS, Behind the Code took the chance to collar company manager Aurélien Levy and front-end developer Hidde de Vries to see what they had to say about accessibility, better known as a11y. Topics under the spotlight were the current state of web accessibility, the reasons why the number of accessible websites is so low right now, and the ways that could be fixed. An accessibility specialist and a web developer, de Vries has lots of experience building accessible websites: His roster of clients includes Mozilla, the Dutch government, and the city of The Hague. Levy, meanwhile, is one of the authors of the French Accessibility Guidelines (RGAA) and has worked on integrating accessibility within the production workflows of both private companies and government departments.

Please explain why accessibility is important to you.

Aurélien Levy: I’m the manager of Temesis, a company based in Paris that works mainly on accessibility, but also, on everything related to corporate social responsibility in the digital arena. Accessibility is a subject that I first became interested in while working on the website of a motor-disability association, Association des Paralysés de France [now APF France handicap]. I immediately found accessibility very interesting because it combines human, design, and technical aspects.

Hidde de Vries: I’ve been a front-end developer for more than 10 years. I originally got interested in accessibility, because my first boss was involved with the Dutch web guidelines. This meant that the first time I made a website professionally, I had to work according to accessibility standards. And, for me, accessibility achieves the goal of the web in a way, because the web is meant to be for everyone. As a developer, I know that’s technically possible, so I feel a certain drive to make that happen.

What does accessibility actually mean in the context of websites?

HdV: To me, web accessibility is about ensuring the web works for people with disabilities, in other words, it is about making the web work for everyone.

How many people currently need accessible websites? And what is that figure projected to become?

AL: That’s not an easy question to answer, because there’s some data that you can’t get from users. But I estimate that between 10 and 15% of the population is, or will be, at a certain point in their life, disabled.

HdV: I ended up with 20 to 25%, because I also included people who have difficulty with reading and writing and that sort of thing, as well as people who have temporary barriers (like a broken arm or stress) or situational impairments (like carrying a baby on one arm or looking at a screen in bright sunlight).

AL: And as the population ages, the more people will have difficulties seeing, hearing, and moving. So the need for accessibility will definitely increase in the future!

So why is the percentage of available accessible websites currently so low—approximately 2% in France, for instance?

AL: I don’t think the problem comes from a lack of interest on the part of developers or designers, but mainly from a lack of awareness. If you look at the field of architecture, every architect needs to mention knowledge about accessibility on their résumés— it’s mandatory for them to know how to design buildings that fit the needs of someone in a wheelchair, for example. There aren’t the same requirements for people learning web design or web development, and the consequence is that, today, the vast majority of developers don’t even know that blind people can use a computer! And it’s a vicious circle, because since developers don’t know about accessibility, they don’t build tools that would integrate it within websites. Most of the JavaScript libraries, web components, or CMS out there don’t consider accessibility.

HdV: I’d like to emphasise that, in principle, it is hard to know how many websites are accessible. These percentages are often based on surveys with automated tests, which only cover some of WCAG and say more about quantity than quality. In my opinion, private companies tend to give priority to things that will allow them to make money. And they don’t always see accessibility as one of those things. As an accessibility community, we should probably get better at making the business case for our clients.

AL: That’s true—people tend to focus on the cost of accessibility. But actually, it’s not the cost of accessibility itself, it’s the cost of adding something new to your existing development process. So it’s exactly the same as the problem with security, for example. But if accessibility is considered a core value of a brand from the start, there is no such thing as a cost issue. If you look at Apple, for instance, they aren’t perfect, but every product they launch integrates accessibility from the start, and all the products, including iPads and iPhones, have a screen reader, a screen magnifier, and a lot of features for people with disabilities.

And companies should also consider that making their websites accessible is a way to reach new customers and actually make more money! Indeed, even if a company spends $1m on making a website accessible, if they sell something at $9.99 a month they only need to reach 10,000 disabled users worldwide during one year to compensate for the costs. Companies should not forget that, behind accessibility, there is a market with business opportunities!

What are the three most frequent and impactful accessibility issues right now?

AL: Keyboard navigation is one of them, for sure. It is not correctly dealt with by most of the websites. As many developers don’t know the value of semantics, they don’t use rel links or rel buttons that, by default, will be operable with a keyboard. They just use divs with onclick JavaScript. The consequence is that the links and the buttons can’t be activated by the keyboard and are not announced as links or buttons for the screen reader. This prevents blind users as well as users with motor disabilities from using the website, as they may not be able to use a mouse, but could instead use the tab key or the arrows.

Another frequent issue is non-adapted color contrasts on a website. Designers often face difficulties about this because some brands prefer to use very light colors, and the designers are not in a position to change that, so they have to deal with it while still making sure that the content is readable. Also, a lot of people tend to replicate designs made by others, which may include bad practice in terms of accessibility. For example, right now, everybody puts text over an image just because big brands have done it. But if you want to do the same, it requires precise artistic direction in terms of the typography and images you’re planning to use. Some of these trends are harmful for accessibility.

The last issue concerns forms. It is important for users to be able to send contact information, to create an account, to log in, and to make orders. Those services are part of the web, so every user needs to be able to interact with forms. That involves letting all the users [with disabilities] know whether there is an issue on the form and what that is, so that they can fix it. In many cases, error messages are not attached to the correct field, so, at best, the screen reader will just read the name of the fields, and the users will not know that there is an error. They will try to validate the form, but nothing will happen and so they will not be able to understand why.

HdV: I agree about the colour contrasts and the keyboard. I would like to add the lack of alternative texts. If you go to very big websites and look at the alternative texts for images, they are often missing, even if, technically, this is easy to implement. The same goes for audio and video: transcripts and subtitles are essential for some users to understand your content.

What would be your best piece of advice for a CTO who is looking to improve the accessibility of their company’s website?

AL: My main piece of advice would be to make sure that accessibility is considered from the beginning of a project. If the UX team doesn’t take the topic of accessibility into account, the experience of users with disabilities will not be very good, even if you try to fix this afterwards. Just look at the existing documentation! The topic of accessibility has existed for 20 years, so there are a lot of resources and a lot of people talking about it. There are international guidelines, such as WCAG, and some governments, including the French government, and public companies like the BBC [in the UK], and private companies such as Google or Apple, have also published useful content about accessibility.

I would also advise integrating accessibility tools directly into the existing development process, as with the open-source testing library Axe, which was developed by the company Deque. This library is now even included in the webhint extension for Microsoft Visual Studio. So when you write your code, error messages appear to remind you that you forgot the attribute of an element. This is the kind of solution that is really interesting, because it reports the issue live, when the developer is coding. For the part of accessibility testing that can be automated, this process is much more efficient than having an external expert look at the code, create a [bug report], and explain the issue to the developer.

HdV: One thing that I’d like to add to that, is that it could be useful to have compliance with the WCAG standard in your definition of “done”. This works best if someone on the team, maybe someone from the QA team, has a good understanding of the standard. And when developers demo a website that is supposed to be “done,” trying to demo it without the mouse can be a great way to showcase how robust the product is.

What tools, libraries, and frameworks would you recommend to help take accessibility into account?

HdV: One thing to keep in mind in that regard: a lot of libraries claim they are accessible, but not all of them are. I think using web standards like HTML and CSS really helps, because they are accessible by default.

AL: As Hidde says, most of them are far from being perfect but you can achieve some results by using the components included in the front-end framework Bootstrap, version 4 onwards for example. I also recommend React Router, a router in React that makes the screen reader aware that a page has changed so that it can announce the new title of the page. When using React by default, everything is updated dynamically on the same page, which means a user with disabilities will not be aware that the page has changed when he clicks on a button.

What is the best way to test the accessibility of a website?

HdV: For me, the best way involves a combination of automated testing and manual testing. The manual tests will need to be done by accessibility experts who know the standards and will be able to check the website regularly, as you would do for privacy or GDPR. In addition to that, where possible, I would also recommend including users with disabilities in user groups when testing websites. It can be tricky to put something like this in place but it is definitely a good testing practice if you can make it happen, and it is complementary to the other tests. Those three layers of tests each provide different values!

AL: You can easily find associations of disabled people that will be happy to help you. But as Hidde says, it can be difficult, as you need to have every kind of disability represented. For example, a blind user will not care about [colour] contrasts, while it is still an important issue to solve for other disabled people. But keep in mind that tests from users with a disability will make it possible to detect micro problems that regular users will maybe never have mentioned but affect their experience on the website, too! So these tests can be extremely useful for all users.

Using an official testing methodology can help, too, because accessibility standards are huge and complex. I am one of the authors of the official French testing methodology to ensure that developers and companies are conforming with international accessibility standards. This document explains what to test and how to test it. It includes basic tests, such as using your keyboard to navigate round the website, increasing the font size, zooming in on the page but also checking that the focus [of your mouse] moves to the field when you click on the name of a field [and not on the field directly]. Using such a document will help testers become more efficient when testing a website.

What kind of initiatives could really help increase the number of accessible websites?

HdV: Legislation is definitely one of them! Even though it is not my favorite way to argue for accessibility, it really helps because it ensures that people at the top of an organization pay attention, just like with GDPR. Thanks to legislation, I have been contacted more often recently by companies that want my advice because they have heard they will be penalized.

AL: Yes, many countries have regulations about accessibility. And there is a lot of ongoing litigation in the US currently. So big companies are investing in accessibility because they don’t want to face class action, for example. In France, a law concerning accessibility has existed since 2005 and was updated in July 2019 to extend its application to companies with a revenue of more than €250m per year.

HdV: Search engines also have a role to play. Impacting on a website’s SEO rank if it isn’t accessible could really help. They’ve already done that with performance and it seems to be effective.

AL: But I think, currently, that the most interesting initiatives are available for developers rather than the users. Most of the developers’ tools on the browsers include some kind of accessibility testing, which is really useful because it helps developers to take accessibility into consideration in their daily work. Developers would then become more aware of this topic.

Do you think facial recognition could be a good way to improve accessibility on the web in the future?

HdV: Facial recognition can probably help for web accessibility. I would say we need to be sceptical though, because it’s not necessarily going to do what it promises. It’s the same with AI, I think. Human power will still be really needed for the advancement of accessibility features.

AL: It can definitely be helpful with some interfaces, but not necessarily for websites. For example, when the Xbox [360 with Kinect] was released, a lot of experiments to help people with disabilities were carried out with the motion detector. All those AI things, facial recognition and movement recognition, are very interesting but it is still at the research stage and it is not always usable in daily life yet. But what is really interesting is that technologies invented for disabled people can also be useful for all people. TV remotes, voice recognition and even phones were originally created for people with disabilities. And now everybody uses them and couldn’t live without them. So all this ongoing research could generate mass-market products with some adjustments.

This interview has been edited for space and clarity.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by Catherine Pearson