CMOS #19: Job van Achterberg - Inclusive design
Interview with Job van Achterberg, a freelancer in the Netherlands, about implementing accessibility in websites. We got a wonderful list of tools and suggestions on how to make our website accessible to more people!
Job van Achterberg
Okay, well we need a website, and it needs to be dynamic!
Oh, I think I've read about this Perl, and that you can build dynamic websites with it, so let's try that!And then you get into frontend because you're the only guy there and,
Okay, so how does this database thing work?And you kind of teach yourself. And now I'm here on your podcast, so I guess it's finally complete now!
I am a volunteer firefighter, this means sometimes I have to be gone for maybe an hour, maybe more.And as long as there's an understanding that I will make-up those hours later, and if the client's okay with that, that works really well. But I'm really lucky to have understanding clients.
Nobody knows you're a dog.And they had this picture of a dog using a computer, I think it was FarSide comics, I'm not sure. But the whole idea is, on the internet, nobody knows if you're wearing glasses. Nobody knows if you're using a screen reader, if you're using the keyboard or the mouse, but there are so many sites that you can only use with a mouse, or you can't keyboard through them, or you can use your keyboard, but you don't get a visual indicator of what's currently being focused.
And I would say that probably 80 - 90% of the web is really hard to use for people with disabilities, for people who are just using keyboards, for people who are eating a sandwich and only have one hand available, and they want to still browse the web.
So the web was initially conceived by Berners-Lee with the idea of a medium that would be available to everybody.
And there's this nice quote on there that you see everywhere, like
The universality of the web is an essential aspect.
And then it's kind of frustrating to see that so many large parts of the web are inaccessible, while it's not actually too hard to make it accessible.
And it's just a matter of spreading that knowledge.
And a lot of developers came up to me afterwards, saying
Oh well, this is really interesting. We'd like to learn more.
And that's a great sign, at least from the Perl community itself, that they really want to make sure things improve.
I gave the same talk at the Dancer conference in Vienna and I get the reaction like
Oh can we see how accessible meta::cpan is?
You know, the Perl package website?
And I said,
Sure, let's check, and so I ran it through Tenon.io, which is an online accessibility checker that analyzes your page, see how accessible it is.
And I said,
See, here's this nice overview of issues!
And right away they wanted to sit down and see how we can fix this, which I think is just a great attitude the Perl community has.
To not be defensive,
Oh, well, you know, people are trying...
It's just like
No, let's sit down and fix it. We know there are problems now, we can get work done.
And I think if we can get that sort of attitude to much more of web development, towards this whole,
It's our job, to make sure what we build works for everybody.
We can really make the web better for everybody and we're all getting older, I mean, lots of us have glasses, I only have one decent eye.
I mean, I've tried to set some age, I know my eyesight's going to get worse, and it's also in our own interest to make sure that what we build works well for people, because you sometimes hear from companies,
Oh well, people with bad eyesight or disabilities, they don't use our web shop. Because we cater to the young people.
Yeah but our generation is also going to be older in 20 years, and we're still going to be doing all our shopping online, so...it's going to affect us more and more.
And I'm kind of on my venting chair here, right now!
But what I'm trying to do is make projects I work on accessible and I organize meetups, where we bring developers and designers together, and we try to create this exchange of ideas and knowledge to make sure that we know how to make stuff work, for as many people as possible. So yesterday we had one [meetup], and we had three speakers, which was very much around how to design a website, while keeping the very broad Autism Spectrum in mind. So what are the things we should consider with moving content, and bright colors, and lots of moving things? And changing context quickly? And it is not so much having to check off all the little checkboxes, on making sure something is accessible, it's more about knowing what you're building, thinking about what is it going to be like, and making sure that you test it. That you run it by people. It's not so much trying to get the list right, it's about thinking about what you're building. Which I think is a good idea in any discipline.
Hey, can you put this on GitHub?Because there's actually a little bug in one of the filters, so it doesn't cover the entire page, and since they're basically just SVG filters, that can probably be fixed, and we can probably even add more filters, and make it an even better tool, because he won't have to do it all by himself. He can just leverage this whole open source and get more people to contribute.
Hey, I know you're open to opening it up. Can you?And I haven't said that there's...or did I? I'm not sure, I might have told him that there's a bug, maybe, I don't remember.
Hey, the snow filter is broken.Maybe he'll say,
I don't have time the next couple of months.
Oh, I'll have a look, maybe I can fix it.So, and I'm just speculating, I don't know the guy personally but I'm just saying, this is how...
There's NVDA, which you can download, and the code's on GitHub.
And essentially, it's been written by two blind developers, Jamie and Michael, and it's just really impressive, and it gets better all the time.
They've done so much stuff, so many great features, that even competing screen readers like JAWS implemented only years later, that, I mean I'm so impressed with these guys.
But I mean, it's open to everybody and for instance, I was testing some accessiblity feature of a website I was building, and I wanted to know how live regions worked, and a live region means that you're using a specific attribute on a container like a div, to say,
Any content in here, if it changes, re-announce it to me.
So you call it the live region.
And I wanted to know how that worked, because I wanted to know how the different settings influenced the way new content was announced to the reader.
So I went to GitHub, and I looked through the code, and I did some grepping, and there it is.
And with JAWS I wouldn't be able to do that, but this gave me insight in how the tool worked.
How I could maybe improve my website's accessibility.
And even if there's a bug, other people could fix it.
A funny anecdote is, it's written by blind people, so it's a lot of C++ code without newlines or spaces, it's kind of hard to read.
But you can, of course, run it through a prettifier.
There's also a newer one, at html5.validator.nu, which is more of a modern, living-standard, HTML5 validator.
But they're both open, so you can just go through the source on GitHub (W3 and Nu HTML5). The newer one is written in Java, I think, but what's cool about both of these tools, is that they have an API as well. So you can use curl, or whatever client you write yourself to just query, the report per page, you get JSON back, you can analyze the JSON, the spec is documented, and then you can, for instance, include it in your task runners, like a Grunt or Gulp or your continuous integration tooling and so, whenever somebody pushes a change to the frontend, you run it through the validator, if it throws up a warning, then hey, it doesn't pass. So I think it's really nice, that again, that stuff is open, because other people can contribute, you can adapt it to the way the HTML spec changes as we go forward, and new items are added to the spec. So, and of course, the W3, it would be weird if something of the W3 is closed, because that stuff is so integrated with the rest of the open web, that I pretty much take that for granted.
Thinking of all the tools I'm using, so there is another one, there's actually two other ones, because I'm talking about validation and the HTML validator and the W3 validator, they're pretty basic. So the W3 validator is basically just document-side declaration validation, schema validation. And the HTML5 one is a bit more modern, it will catch a bit more things but there's only so many actual problems you can find with those.
But there's also a toolkit that's make by Deque Systems, which is an accessibility company, they do mostly consultancy around accessibility work.
So since it's a rule-set, you can include it, they've built it that way so it can be included with your own tools.
So you can use their checks to validate your own projects.
And it's open source, so lots of other people are also adding rules to that.
But for instance, those are rules that will go a bit deeper and say,
Oh, your headings aren't in the correct order.
You're starting with an h2 heading and you actually don't have an h1 heading.
You're not using the value for this ARIA attribute correctly.
Or basic stuff like contrast rules or font-size rules, and it is difficult to catch all accessibility problems.
I don't think we'll ever get there, there will always be an amount of work that you have to check manually.
There's always going to be the human factor, because otherwise, you get back to that accessibility checkbox that I discussed already.
And oh, I had this good point, and it flew away, it's gone now!
So, I totally lost my train of thought, it's terrible.
There are, again there are tools that will mainly catch a lot of the, for lack of a better term, low-hanging fruit.
For instance, the aXe tooling I talked about earlier, the Deque aXe, there's a Chrome integrator so what it does, is in your Chrome inspector tools, and there's also that for FireFox, but in your Chrome inspector tools, you get this new tab, it says
aXe, and you can say,
Analyze this page.
So it chugs for a bit and it shows you this whole list,
This element has this problem, here's how to fix it. This element has that problem, here's how to fix it.
And that already shows you a lot of the basic stuff that you can catch that way and the whole point of that, is that the tooling prevents, that sort of automated tooling, it prevents regression.
And that's the most important thing, because accessibility shouldn't be something you do at the end, when you're done.
Okay, I've built my site, let's see how accessible it is.
It should be part of the beginning, like you start out writing tests and documentation, and you start out writing decent, accessible code.
And you iterate and iterate and iterate, in a nice agile fashion, but in the same sense, you just make sure that you run your code through your automated tooling and you catch all the basic stuff there.
And for everything else, there's manual testing, like you can hire companies for that, or you can, of course, ask friends to run through your site. But there are entire companies that specialize, by having a diverse set of people that will go through your site, and tell you what problems they can find. And there are companies like Deque and the Paciello Group, which will audit your entire site, for a fee of course. So yeah, if you don't have that option, these open tools are a great alternative to already make sure that your baseline is pretty good. And personally I'm just happy people will take the effort to make sure that their pages are accessible.
Published on 2016-10-28