I was chatting with some front-end folks the other day about why so many companies struggle at making accessible websites. Why are accessible websites so hard to build? We learn about HTML, we make sure things are semantic and — voila! @— we have an accessible website. During the course of conversation, someone mentioned the Domino’s pizza legal case, which is perhaps the most public example of a company being sued because of a lack of accessibility.
Here’s an interesting tidbit from that link:
According to CNBC, the number of lawsuits over inaccessible websites jumped 58 percent last year over 2017, to more than 2,200.
Inaccessible websites are not just a consideration for designers and engineers but a serious problem for a company’s legal team as well. Thankfully, it seems more of these cases will be brought to trial and (my personal hope is) this will get folks to care more about semantics and front-end development best practices. Although I’d like to think that companies would do what’s best for the web and make websites that meet the baseline requirements without a legal threat, we absolutely need to make inaccessible websites illegal for folks to really pay attention to this issue.
However! I also worry about attributing what might simply be a lack of knowledge to malice. I reckon a lot of websites have bad accessibility not because folks don’t care, but because they don’t know there’s an issue in the first place. As my conversation with front-end engineers progressed, I realized that the reason accessibility isn’t tackled seriously probably doesn’t have anything to do with bandwidth, or experience, or money.
I reckon the problem is that the accessibility of a website can be invisibly and silently broken.
Here’s an example: when developing a site, JavaScript errors are probably going to be caught because everything breaks if something goes wrong. And CSS bugs are going to get caught because something will look off. But the accessibility or performance of a website can go from okay to terrible overnight and with no warning whatsoever. The only way to fix these invisibly broken things is to first make them visible.
So, here’s an idea: what if our text editors caught accessibility issues and showed them to us during development? It could look something like this:
I’m sure there are a ton of other ways we can make accessibility issues more public and visible. There are tools such as Lighthouse and browser extensions that are already out there, but making accessibility (and even performance, another silent fail) a part of our minute-to-minute workflow ensures that we can’t ignore it. Something like this would encourage us to learn about the problems, give us links to potential solutions, and encourage us all to care for a relatively misunderstood part of front-end development.
It’d also be great to have native support for a hybrid click/keydown event specifically for reproducing link behavior.
I agree with you, but it should be enough to polyfill (assuming the relevant mouse and keyboard events are allowed to bubble to the top of the DOM). Just attach a handler for “click” and “keydown” events to the document (), and if the click or keydown (Enter key for links, Space key for buttons, checkboxes and radio buttons) occured on a link or button/checkbox/radio, dispatch your “hybrid” event from the originating element. Then you could attach listeners for the hybrid event to any desired link or button.
I have written some pretty inaccessible code, and it’s not because I didn’t care. Actually, when I started to try and write accessible code, I made things even worse.
What I propose is web accessibility be taught from the very start of a web dev (and design) education and companies should require certification that they pay for. Also, we need Congress to actually make WCAG a legal requirement. Even though websites are covered by the ADA, there are still no legal standards for web accessibility like there are for brick and mortar spaces.
I know what you mean, making things worse :-D
I reckon it’s pretty challenging. I remember working on a piece and being very satisfied with the outcome. Thing is, since I had a pretty clear view and knowledge of what was going on, my brain connected the dots. When a sight impaired colleague came to give me a hand, I was disillusioned fast :-D
Agreed! New Devs fail to be taught correct/accessible semantic HTML5 and nothing about ARIA. I have been an accessibility SME for 20+ years. a11y education is a problem.
I think there is a lot of layered answers to why they aren’t.
For my personal experience, here are some:
Legacy sites – We have sites that were built in 2007 still in production. They have lower business priorities, so they are often ignored.
Content Contributors – We use a content management system that is utilized by many people of varying competencies. And not all do their due diligence. We try to catch it but it doesn’t mean we see it all the time.
Bandwith – There is only a couple of developers with 60+ websites. And we hold a lot of hats beyond “developer”.
Third Parties – We use third parties for things like our E-commerce system. Some have not been very receptive to our feedback. And it’s not easy to just switch them out when they are tied to legacy POS systems and the like. In other cases, we were promised things that were fully compliant with WCAG AA, but I found issues with some of the lesser-known rules.
Lack of Legal Clarity – There are no REAL rules, just a lot of talk about using WCAG 2.0 AA. But, even if you meet that, there is no guarantee we won’t fail ADA compliance. The best we can do is shield ourselves from looking like the easy target.
What about Matterhorn and PDFs? Emails?
Rather than delegating it to the text editors, perhaps we need an HTML5 accessibility linter. There’s something like this for React’s JSX, I believe, but a quick search didn’t turn up anything for HTML more generally.
A linter can be integrated with a variety of dev environments and (more importantly) a CI pipeline, rejecting commits that don’t meet baseline rules for accessibility.
A linter would only catch some things and would likely cause folks to write a lot of extraneous code (see blog posts about the misuse of ARIA roles to see how this already happens and causes issues). An accessibility test suite is a better option in that it could catch issues around interactions, which is much harder to do via linter.
I would love to see options for accessibility auditing as part of a CI process. Having a build fail due to an accessibility regression would be awesome, though I can definitely see how it could be tricky to implement something like that since a11y becomes a very complex thing to audit when interfaces get more and more intricate.
Most accessibility issues are contextual. I am blind. If you do not add proper context, listing HTML is useless.
Typo: meant linting.
What browser extensions/tools could front-end devs be using to help make the accessibility problem easier to solve? It’s easy to say there’s tools out there, but links to some would be helpful!
WAT
WAVE
aXe
The (beta) “Webhint extension for Visual Studio Code” might help…
https://webhint.io/docs/user-guide/extensions/vscode-webhint/
It makes use of the “Axe Accessibility Check” (based on axe-core)
https://webhint.io/docs/user-guide/hints/hint-axe/
See also : “Getting hints from Visual Studio Code”
https://medium.com/webhint/getting-hints-from-visual-studio-code-69118e48de1b
I spend a significant amount of time explaining colour blindness or hover and focus styles to designers or clients. Often these discussions are met with “it’s what the client wants” or “we can fix it after launch”. So I think accessibility often goes wrong pre-development, and can 100% see why, partly because of that, some devs don’t bother making (or in some cases, learning to make) accessibility a priority.
MSFT fan are we?? Webhint is a nice tool though not v well known. Very customizable.
Nice post. I find my problem is the actual design, rather than the coding practices. Getting the same website to look attractive to people with and without visual impairments is something I personally struggle with. The many accessibility rules limit the use of colours and shades, many images, the amount of content on each page, etc.
On the coding side there’s not just the basic HTML, coding now, there’s also WCAG, ARIA and structured markup to implement. The code gets very ugly, very quickly.
As for code hints, VS Code has a few extensions to help out.
Is that an actual Atom plugin or just a mock-up?
It’s VSCode, not sure about the linter tool though
That’s Visual Studio Code and I believe it’s a mock-up
This is what ember-template-lint does. It’s worth checking out. There are also some VS Code extensions that do similar things.
Axe provides a lot of tools, including browser extensions and an engine that can be used in tests
https://www.deque.com/axe/
https://github.com/dequelabs/axe-core/blob/develop/README.md
Siteimprove browser extension
https://chrome.google.com/webstore/detail/siteimprove-accessibility/efcfolpjihicnikpmhnmphjhhpiclljc?hl=en-US
“…we absolutely need to make inaccessible websites illegal for folks to really pay attention to this issue.”
Yes, let’s outlaw bad design implementation. That’ll boost interest in front end development and bring more talent to the industry. Oh, hey, that’ll also solve the issue of poor accessibility protocol!
I find it hard to provide pretty and accessible solutions. You need to understand the a11y components, and it’s so vast. When I first looked into a11y documentation, there were hundreds of page to cover and it was impossible to not be bored at some point..
Web accessibility has been a focus of mine for at least five years now. I’ve implemented versions of nearly every custom component WAI-ARIA mentions in its authoring practices, and despite all of my knowledge, making accessible websites is still very difficult. One of the greatest challenges developers will face is the lack of consistency and compliance between assistive technologies and browsers (sometimes operating systems also influence this).
It is frequently the case that I will implement something exactly to spec only to find that it works in 25% of the assistive technology/browser pairings. When a dev can’t trust the screen reader and browser to work according to spec, and they have to start creating tables of test results to figure out whether they should try to make things work in a hackier-but-potentially-more-supported way than WAI-ARIA advises, there’s a big problem. I really don’t think that it’s fair to developers to impose this burden when the makers of these tools are providing incomplete implementations. Most developers will be new to writing accessible components, exacerbating the issue even further. If they can’t be sure they did it right, even when trying to test it for themselves, because maybe their tools just don’t work, that makes it way harder to learn.
“We learn about HTML, we make sure things are semantic and — voila!”
Easier said than done.
I’m one of the few a11y advocates at my current company and tackling semantic errors/issues on our system is quite a challenge. First, it is an old code base that didn’t follow any style-guide and didn’t care about user flows. We’ve been ‘modernising’ it piece by piece by separating FE code in re-usable components. Components are cool, but when we start composing a layout, controlling aspects of semantics like heading order and landmarks becomes difficult.
One solution might be using wrapper components that allow to pass optional props like heading level.
I think a11y is not a matter of just learning HTML and semantics, it is a whole team effort and UX designers are a huge, huuugeee part of the solution (or problem)
Perhaps HTML5 can introduce a debug mode. For example a tool like Dreamweaver doesn’t let you miss things like this (on a very basic level) it tells you you are missing alt tags for example lol.
The way I see it is there are a few classes of bugs on websites, including……
Breaking bugs – The website doesn’t function because of them
Visual bugs – The website works but margins are wrong, button is the wrong size etc.
Accessibility bugs – The website does everything it’s supposed to and looks fine unless you’re using accessibility tech.
The trouble is that if you mess up on the first one the client won’t pay you. The site needs to work. If you have a few visual bugs you’ll probably still get paid but the client may complain a bit and you’ll probably want to fix them next. If you have accessibility bugs then you’re need to go to extra effort to even know they’re there, the client 90% of the time isn’t even going to notice.
So, accessibility probably isn’t that hard, I don’t think that’s the problem. If websites didn’t function properly (i.e. wouldn’t run) until accessibility problems were fixed we’d all be experts on accessibility by the end of the week.
i’ve been a web designer for almost two decades, and i know for a fact that a company without a compliant website is almost 100% caused by lack of knowledge instead of malice. none of the web designers on my team—some are fresh out of college, some have been doing this as long as i have—know what the laws and requirements are of an ADA complaint website are. it’s not something that’s taught in universities, it’s not really ever covered on online blogs like this one, and you never hear it discussed about anywhere else, really.
honestly, and ashamedly, until i read about the Domino’s case a week or so ago, i didn’t even know there WERE actual laws and requirements i had to adhere to as a designer. of course, i knew about alt tags and what not, but i always had viewed that as a convenience to users with screen readers or whatever. i didn’t realize it was required by law.
the sad part is, i’ve searched several times in the last week or so what the actual laws and regulations were, and all i can ever find is a bunch of legal jargon or websites seemingly written by lawyers. there’s nothing out there i could find—even from traditionally easy-to-use companies like mozilla or google—that was concise, easy to read, comprehensible, or user-friendly. I’m not asking for a bulleted checklist of rules i could just check off, but finding anything that’s isn’t frustratingly impossible to understand is impossible to find.
I know you didn’t ask for a checklist, but I think Vox Media actually has a good one: https://accessibility.voxmedia.com/ I especially like that it covers accessibility across the product — it’s not just a dev’s responsibility. Universities and government agencies also often have good docs on accessible web practices, since they’ve been at the forefront of this consideration for some time.
Also, Google includes accessibility in its web fundamentals materials (both as docs and as a free course on Udacity) : https://developers.google.com/web/fundamentals/accessibility
Finally, if you’re looking to level up your accessibility know-how, I recommend this weekly newsletter: https://a11yweekly.com/ It always has a section for newbies to accessibility and is a good way to keep accessibility front of mind as a dev.
Indeed. WCAG isn’t taught at universities. As an accessibility developer I learnt WCAG by doing several courses and working with Vision Australia many years after I completed my degree. I’m glad that I did as Online Accessibility is the future of web development, it plays a centra;l role in my business and the future looks bright each day.
So I have been looking into making the things I build more accessible and the issue I run into is time. I just don’t have the time to test it and to be honest I don’t have the knowledge of all the different ways of testing accessibility. So I can start a project with the intention of it being an accessibility masterpiece but as deadlines loom I am forced to stick to only focusing on semantic markup.
The second part about accessibility is that its not just about screen readers and color contrast. There is a wide range of disabilities out there that are more than just users with screen readers. So if the whole team isnt thinking about it and working towards this then no matter how accessible your code is it still won’t be compliant.
What we need are more tools and resources that can help us all, developers, designers and content creators alike. We need ways like mentioned above to help us QA this, is there a Browserstack for assistive technology? We also need our product owners and stakeholders to understand that doing all of this takes a bit more time but it will open up their product to a new audience.
Accessibility is also hard because accessibility is about an individual’s “access” – and that has a huge range of variation that no ruleset (as yet) can completely cover. This is why WCAG uses the term “guidelines”, not rules. It’s not possible to cover every possible scenario of web accessibility as it is as individual as every person, variable across time, and ultimately changeable as technology and tools improve.
This talk by Heydon Pickering solved most of my concerns about accessibility. (warning, some swearing)
The key point I got from it (re: accessibility) is that simple HTML is accessible by default. So the less code your write, the easier it is to make it accessible.
In some aspects, accessibility doesn’t break quietly, so long as you’re continually using your site with AT. I try to always periodically use my sites with keyboard only, my eyes closed and screen reader on, etc. So if something breaks, it doesn’t get very far before I notice it (ideally).
So I think part of the solution here is to educate beginning web developers to test without their mouse and eyes at least 1/3 as often as testing with; as a matter of habit and routine, not of “advanced” best practices. Getting used to browsing this way will also help them sympathize with and have a deeper understanding of users with disabilities, and know all that much better what to do when they encounter accessibility issues.
Accessible websites really aren’t hard to build at all. It just needs a little bit of awareness and education. I like your idea of accessibility issues being flagged within a code editor, although there are already tools like pa11y that can easily be integrated into a dev’s workflow https://pa11y.org/
What I love are the reasons for not doing it – time and resources have been 2 excuses used, which effectively tied my hands at the time. And only now, since customers are now insisting on it (even though they shouldn’t have to), is time been given to do this. Also the highest standards possible, require your website/application to work with JS turned off :)
Also what is accessible? Keyboard accessible? Contrast color high enough for those with colour blindness? How does it work with a screen reader? How does it work for a user who doesnt use a keyboard, or even a mouse to navigate? If you are going to implement accessibility, the first thing to do – get an accessibility review done – there are companies out there that specialise in this area. Then look at what you need to deliver, what minimum level you are looking at. Then when you have developed – get it reviewed again. Develop more, review more, etc. Its a continual process, especially when you are adding new features/functionalities.
And a statement of conformance is pretty much key, this will inform your end user, exactly what you support (e.g https://www.bbc.co.uk/guidelines/futuremedia/accessibility/)
I’m a front-end dev turned accessibility consultant, and I completely agree that it’s lack of knowledge, not malice, causing the problem. I can count on one hand the number of people who were prejudiced or hostile towards my input, while everyone else I’ve met in an 8-year career so far just wanted to find out what the right thing to do is. I’d love to get accessibility taught at the beginner level, I think it would make a huge difference. Another place people can help is to make sure their tutorials and tools produce accessible results too. CSS Tricks is always so good at that!
Not everyone can afford a consultant, so I wrote a little learning plan for accessibility – it’s still a draft so if you have any suggestions for improvement I’d love to hear them. https://github.com/stringyland/a11y-learning-plan The plain-English version of WCAG from WebAIM is great too: https://webaim.org/standards/wcag/checklist
I don’t buy the “it’s too hard” argument though. People learn new frameworks, new features all the time. They re-write entire codebases to include hooks or whatever the new hotness is that week. Web devs are smart and more than capable of putting in the effort needed to learn accessibility.
Legislation has helped a lot outside of the US for promoting digital access too. It creates a common standard or baseline everyone can work towards and share resources for. I hope the
“what if our text editors caught accessibility issues and showed them to us during development?” Webhint.io does exactly that. :)
For VS code I should say, using aXe accessibility rules.
Is there a need to do anything more than scoring reasonably high on Chrome Lighthouse’s Accessibility test?
There are NO apps that identify or recommend fixes for more than 15-20% of accessibility issues. I should know. I am blind, and I have worked with Microsoft and many Fed Agencies fighting lawsuits. You either know your stuff, or you don’t… And most UI/UX folks still don’t have a clue.
I guess that means I have a job security.
Most accessibility tests look at the static page — so they make sure you’re using semantic HTML, your images have alt text and the contrast is appropriate. These are all important considerations, but they fail to test interactions — can a screenreader user tell if your hamburger menu is open or closed? Are form error messages read aloud by screenreaders? Etc, etc.
These require either more customized tests or hands-on accessibility testing.
Yes, because as good as Lighthouse is, it can only check for issues caused by malformed code. There are issues to do with content and interaction which need manual testing. You need to check for all the items on the WCAG 2.1 criteria list – there’s a short version put out by WebAIM: https://webaim.org/standards/wcag/checklist and The A11y Project has a good primer on basic manual testing too: https://a11yproject.com/
Well I can certainly appreciate that there’s more to it, and we need to do more. However, manual lists won’t get us there – people just won’t use them. We’ve also used WAVE and Axe (Chrome extension). The more we use those, the more we learn and incorporate the techniques in our standard website build process. How are those tools at resolving real issues from your perspective?
Hey Sean, the answer would be yes – more must be done. Lighthouse’s a11y audit is meant to more or less steer you in the correct direction and give you an idea of how well you’re doing. Not to stir the pot, and attempt to discredit the Lighthouse’s a11y team’s work, but this one blog post made the rounds when someone gamed the auditing tool, and scored 100 on a site that wasn’t accessible. Read it here.
https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/
Of course some twitter threads came of it, but one thing which is mentioned – and ignored – is that Google adds that it “the Lighthouse audit that it can’t test everything” and “we also include a whole set of manual audits with documentation explaining how to do them.” (via Rob Dodson).
Most a11y professionals will tell you to not overly rely on automated tools. They serve well, but some cases will always slip through the cracks. I happened to have a convo w/ Rob about this, and part of this issue – I felt – was the score. Ppl hang on to that like a gold medal. So 100 feels like you’re done – but you aren’t really.
re: your second comment about how useful the existing tools are… I’d say Chrome’s Lighthouse is my favourite because it’s just so easy to use, but aXe and WAVE are good too (I’ve heard there’s a new WAVE update coming soon!). They’re very good at what they do, and give good recommendations for fixes too. But an automated tool can only cover 20 to 25% of the potential problems. Still, that’s 20% you don’t have to deal with manually like we used to have to do just a few years ago. The mismatch is because accessibility is a problem grounded in human variation and flexibility, and automation is all about replication and pattern-matching. It really does need human attention both before development (in the design and content) and in developer testing of how things actually work in the real world once we leave our nice tidy dev environment. Definitely keep using Lighthouse! But dig into it’s recommendations for manual tests as well, or look into Microsoft’s Insights for more manual testing processes you can follow.
I can confirm that the reason developers do not practice accessibility is simply that people don’t know about it. Before I moved into accessibility auditing myself, I worked for 4 years as a web developer contractor, starting in 2012. Moving around from one short term 3 month or 6 month contract to the next, including working with some very well known big companies with very large websites. During that period I never heard anyone say “We haven’t time for it”, or “We can’t afford it”, or anything like that. The fact is I never heard anyone mention the word “accessibility” once in all that four years! Nor the acronym “WCAG” either. Not once, not by fellow developers, not by designers, not by management.
Accessibility just was not something anyone knew about. It was only toward the end of that period that I discovered it myself, through seeing some chance reference to it on the internet and exploring what it was about. So I took a job in it with one of the largest accessibility consultancies, then later went freelance.
I view this lack of knowledge as a failure of my new profession to teach the rest of the world. We spend a lot of time teaching each other, and some time publishing stuff for developers to read should they happen to find it. But we spend almost no time at all publicising it to the decision makers in industry and commerce, to managements and boards of directors. Sometimes they only get to hear about it when a law suit lands on their desk.
Be careful relying on automated tools. Getting 100% on Lighthouse, Axe, or whatever else you’re using is not an accessibility pass. It is just an indication that you’re going in the right direction.
Try getting involvement from real people. Use screen readers yourself, test without a mouse, apply colour filters to test the 8 main types of colour blindness, check reading age/level of text, look at the size of elements and think how people who struggle to use their hands might navigate.
I totally agree, but I think if developers got frequent reminders in their editors about this stuff, the amount of general awareness would increase by a lot. They might start to at least think of it like any other code quality issue.
If you use the Webhint.io extension for Visual Studio Code you can get exactly that. It will put squiggly lines under elements with accessibility issues.
Hi Robin and visitors,
Applause for your “Idea: what if our text editors caught accessibility issues and showed them to us during development?”. With a striking warning that not all issues can be found automatically, and more testing is inevitable.
– Also cheers for the education propositions in the comments!
Tools
Not embedded in a text editor, but one click away are some handy tools. Just as you check the HTML-validator and CSS-validator every now and then during the development, for typo’s and more severe things, you can check the accessibility (to a cerain degree) in the same move; and like the HTML- and CSS-validator remarks aren’t always adequate.
With this as habit during the proces, you’ll not need to rebuild main struture of the page if everything else is finished!
Still over 10 years there are for example:
The University of Illinois has a “FAE: Functional Accessibility Evaluator”, which can give a detailed accessibility report for a website (register a free user account), with instrictions how to solve problems. See: https://fae.disability.illinois.edu/
For Single Page Use there is a version of the FAE as Firefox PlugIn (without registration): https://addons.mozilla.org/en-US/firefox/addon/ainspector-wcag/
Another tool is from WebAIM (WebAccessibilityInMind, https://webaim.org/): the WeB Accessibility Evaluation tool WAVE, https://wave.webaim.org/, that can be used online.
Also WAVE browser extensions for Firefox and Chrome are available: https://wave.webaim.org/extension/
Note: I agree with Ashley Sheridan and others: “Be careful relying on automated tools”.
Education
Both validators can als provide excellent services in the practice of accessibility education.
More info: the Web Accessibility Initiative (WAI) of W3C, https://www.w3.org/WAI/, has a description of essential resources for the different roles of involved people with regard to accessibility: from Policy Makers via Designers, Developers, Testers, Educators etc. to Web Users. See: https://www.w3.org/WAI/roles/.
See also: Teach and Advocate Overview, https://www.w3.org/WAI/teach-advocate/
Standards
The WCAG (Web Content Accessibility Guidelines, https://www.w3.org/WAI/standards-guidelines/wcag) provide a lot of usable accessibility techniques. The WCAG-2.1 is the last version: Recommendation of 05 June 2018.
In the meantime the W3C has developed the “Accessibility Conformance Testing (ACT) Rules Format 1.0” (https://www.w3.org/TR/act-rules-format/), a proposed W3C Recommendation of 30 july 2019. From their intro:
“There are currently many test procedures and tools available which aid their users in testing web content for conformance to accessibility standards such as the Web Content Accessibility Guidelines [WCAG]. As the Web develops in both size and complexity, these procedures and tools are essential for managing the accessibility of resources available on the Web.
This format is intended to enable a consistent interpretation of how to test conformance to WCAG and other accessibility requirements documents and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools.”
So the focus on universal accessibility is growing!
A lot of folks aren’t even aware that the Web Accessibility Initiative publishes Authoring Tool Accessibility Guidelines (https://www.w3.org/WAI/standards-guidelines/atag/) that set accessibility standards for software and services used to produce web content.
The guidelines don’t just cover accessibility of the tool itself, but also require that the tool do just what was suggested in this article here: help authors (be they developers, designers, writers, or whatever) create accessible content. These guidelines get overlooked and I think a lot of our code editors as well as popular content management systems could be made worlds better by getting familiar with these guidelines and putting them to good use.
There’s a Web Accessibility extension for VS Code (https://marketplace.visualstudio.com/items?itemName=MaxvanderSchee.web-accessibility) that identifies problematic elements in HTML templates but it doesn’t work in JavaScript framework templates like Vue.
I take that back—It does work in Vue, just not in Pug templates.
Apparently you do not know that even THIS page is INACCESSIBLE to me. The first TWO folds are menu with the content STARTING at the top of the THIRD fold. Further, the content starts with “most public example of a company being sued because of a lack of accessibility” telling me that there is HIDDEN content UNDER the menu on the first two folds.
If you are going to harp on something that needs fixing maybe you should START with your own site BEFORE condemning others. Or to put it the way my mother did, WASH YOUR OWN WINDOWS BEFORE you complain about how dirty your neighbor’s windows are.
Wow, you’re fired up buddy. Take a deep breath and re-read the post. There’s no condemnation here — merely a point that making accessible sites is hard and questioning why that is. No need to bring grenades to a tea party.
Hi. I’m a lawyer specializing in ADA accessibility lawsuits, including website lawsuits. You are right to be confused because the law is unclear. For certain government websites there is a regulation that tracks WCAG 2.0 AA, and for airline websites there is the same, but for most business websites there is no regulatory standard to follow. The rule, which won’t satisfy anybody, is that a website must provide “meaningful access to the goods and services of the website” for anyone with disabilities. As a matter of convenience lawyers and some courts have turned to WCAG 2.0 AA and that is the best starting point for building an accessible website; you just have to know that perfect conformance won’t guarantee that the website meets the ADA standard because nobody knows exactly what that standard is.
I’ll second the observation about testing websites using automated tools. Software tools are incapable of detecting some kinds of accessibility problems and also generate false positives because they can’t do things like distinguish images that are decorative from those that have meaning. The only way to test a website is with disabled users methodically testing every possible user interaction to see if it works.
Actually, it is a common misconception that user testing a website by disabled users is the only way. It is not the only way, not even the best way to test accessibility. Though it is certainly very helpful to include user testing as part of the overall test strategy, you need a trained and experienced accessibility tester to completely test a website – but it has to be someone who can see what’s on screen.
One participant in this conversation has just complained bitterly – and quite rightly – that the the top part of this CSS-Tricks page we are on now is unavailable to them, everything down to the second fold! That’s a huge chunk of content that is untestable by screen reader.
Take some other very common cases – main menu links sometimes cannot be followed by screen readers, putting whole pages out of user reach. Shopping carts frequently cannot be used, or even reached sometimes, by keyboard or screen reader. Or another very common pattern on websites, the “button” that is just an SVG icon or background image inside a div, so screen readers have nothing to announce and the reader user has no way to know it’s there. It needs a professional accessibility tester to see visually that it exists, check it out, and tell the developer what to do about it.
And deaf people checking a video cannot, unfortunately, tell when noises or off-screen events should be included in the captions but aren’t. So certainly get in user testers with all the various disabilities needed. But you need a trained WCAG tester or consultant to do the primary accessibility testing of a website.
Actually, it is a common misconception that user testing a website by disabled users is the only way. It is not the only way, not even the best way to test accessibility. Though it is certainly very helpful to include user testing as part of the overall test strategy, you need a trained and experienced accessibility tester to completely test a website – but it has to be someone who can see what’s on screen.
One participant in this conversation has just complained bitterly – and quite rightly – that the the top part of this CSS-Tricks page we are on now is unavailable to them, everything down to the second fold! That’s a huge chunk of content that is un-testable by screen reader.
Take some other very common cases – main menu links sometimes cannot be followed by screen readers, putting whole pages out of user reach. Shopping carts frequently cannot be used, or even reached sometimes, by keyboard or screen reader. Or another very common pattern on websites, the “button” that is just an SVG icon or background image inside a div, so screen readers have nothing to announce and the reader user has no way to know it’s there. It needs a professional accessibility tester to see visually that it exists, check it out, and tell the developer what to do about it.
And deaf people checking a video cannot, unfortunately, tell when noises or off-screen events should be included in the captions but aren’t. So certainly bring in user testers with all the various disabilities needed. But you need a trained WCAG tester or consultant to do the primary accessibility testing of a website.
Why is accessibility so hard? Who here has been successful putting the toothpaste back in the tube?? Mostly no one.
When you tackle something like accessibility after the fact, it’s even harder to implement than a well optimized site. True a11y professionals will tell you that the best test is with real users. And that takes time and proper planning – both of which are never given allocations.
That said, it can be done w/o real users, but it still must be considered as part of all the easiest planning (and testing ideally). And no matter how you slice it, accessibility challenges will likely go as the site complexities. You write simpler code, and likely will have an easier time making things accessible. Karl Groves of Tenon.io has a great talk about some of the main issues in a11y. Web AIM also had a great piece detailing results from auditing 1M sites – a must read. https://webaim.org/projects/million/
Lastly, we’re lucky enough that in Toronto we have an incredible meetup, who also organize a yearly a11y camp (free, 1 day multi track) and we just had a full on a11y Conf last week – 2 days of international presentations. Book mark this page if you fancy a11y pedagogy. https://conf.a11yto.com
The BBC has an accessibility standards checker that’s available on npm and makes use of Node.JS: https://github.com/bbc/bbc-a11y. It can be used in projects for development and be used against URL’s. It follows the BBC’s accessibility standards which is very detailed: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/
Hello fellow web geeks and front end nerds!
Just wanted to mention something. I’d argue that we need to be careful with how we treat and leverage this issue… like as a community.
From my POV, the answer to the OP question, is budgets. Meaning companies for all this time (in my case as purely a web dev), have grossly under budgeted web development, and web design. Albeit, less so for web design.
I mention being careful, because a legit legal threat like the Donino’s case is EXACTLY the nudge most firms need to re-evaluate production operations. So here’s my hack/patch for that moment:
Instill a web design system that requires all current and new additions to the system (in the UI category) to be fully integrated with accessibility standards prior to being added to the system. That way in practice, and as employees use the design system to make stuff, every single code snippet is already marked up with accessibility attributes along with the relationships of their values.
Take the thinking out of it, and treat it like a baseline standard. Treat them like they’re html, head, and body tags. 24/7/365.25
This simple shift completely changes the dynamics of this problem. Because now designers and devs have to physically delete accessibility attributes to make that component or element un-accessible. Otherwise, it’s all right there and simply needs the correct copy or selector!
But the key to this IRL, is to force the web design system to be a single source of truth for all company builds (where variations of the same system are used across different projects). No exceptions. Therefore it’s by far easiest to repo your web design system, and teach the firm to pull and install from there. Boom. Now the designers truly “get” agile, too. Woot.
At that point, accessibility becomes a normal part of every move on a page. And now we don’t have to worry about waiting for an automated solutions… because we can solve this issue better as just a team of diligent folks through progressive design system improvements. KISS.
Happy coding out there! :)
I found WUHCAG (not to be confused with WCAG) to be a very useful site for explaining accessibility criteria in a clear and meaningful way. It helped me get an understanding of each criteria when trying to learn about accessibility.
The Domino’s Pizza situation was a specific case that falls outside of the norm. They most likley made a conscious decision to opt out of paying extra for accessibility and figured that multiple channels of communication were sufficient.
The extra upfront cost would have been significantly less than paying for the $3+ million retrofit afterwards and the the legal fees and civil suit payout. This is typical corporate behavior though and is not suprising this played out. We saw the same thing with the BP oil spill where they elected to cut corners and save $10 million only to have to shell out court costs and $20-25 billion in payouts. The California fires from 2 years ago where the electric company in the area had faulty equipment that sparked the fire in the dry season decided not to pay to upgrade equipment then was found to have caused the fire so had to deal with a sh*t ton of civil suits government fines and still had to upgrade their equipment.
Corporate culture mentailty – “that law doesn’t apply to us”
I can’t disagree about Domino’s corporate culture, but their case was also based on a mobile app. I also think it is important to understand that accessibility litigation is not driven by genuine accessibility problems; it is driven by lawyers who make money from it. A typical lawsuit starts with a legal assistant running a software tool against a website to find WCAG 2.0 AA errors. If anything shows up a blind plaintiff who is probably on dozens or even hundreds of cases goes to the website and pokes around. He or she may or may not have trouble with the website, but that doesn’t matter because the software report is what the lawsuit is based on and the lawyers do not care if the report includes false positives. They just need a little cover in case there is a claim they filed the lawsuit in bad faith. The suit is filed and the law firm demands between $10,000 and $50,000 plus a promise to fix the website over a period of 18 to 24 months in order to have it dismissed. The lowest possible cost of a successful defense is more than $10,000, so all but the most stubborn businesses pay up, agree to fix the website, and move on. They may pay even if the website is perfectly accessible just because proving it is accessible is more expensive than paying off the plaintiff’s lawyers. Making websites accessible is good business, but it has nothing to do with litigation or avoiding litigation because litigation in this area is driven by greed, not care for accessibility.
Treating accessibility as a development problem is one of the reasons it’s considered hard. (I don’t consider it hard any more)
When we read through the WCAG checkpoints, and accessibility test reports from real users with assistive needs, it is clear that accessibility is a pretty balanced three-way split between content, design and implementation.
Automated testing is not advanced enough to detect accessibility issues from content, for example, if a site has multiple languages, it could test well in one language but not another.
Even when developers are savvy to what makes a solution accessible, they need the designers and content writers to be on board, too.
What if people actually learned what semantics meant, and what progressive enhancement means. If they knew those things, then they could understand and fix accessibility errors before they became a problem.
All these frameworks and UI builders generate rubbish markup: piles of divs and spans, oh and we’ll throw in a bit of aria here that we don’t understand band whose influence we can’t even see because we’re not using screen readers, oh but someone down the line will pick it up and we’ll iterate.
Ugh!