CMOS #19: Job van Achterberg - Inclusive design

Hello there, this is the CMOS, the Code Maven open source podcast and video interview series. My name is Gabor Szabo, I'm your host, and with me is Job van Achterberg. Hi Job! How are you, Job?

Hey Gabor, I'm great! Thanks for having me.

Yeah, I'm really happy to have you. Just to other people who are listening or watching, we know actually each other, for quite a while from the Perl community, from various conferences, but never had a real sit-down and an interview or talking about your past, so please tell me a little bit about how did you get into computers, programming, and wherever you are?

Oh, how far back. It's my parents' fault, they bought this old 32KB BBC micro and, you know it had a floppy drive, you'd turn it on and you'd get a basic prompt. So back in the old days, and it came with these books to learn programming, and that's kind of how that started. You figured out you could make a machine to do stuff and you want to make it do more stuff and that's, yeah, I discovered I liked that and eventually got a job into system administration and got into, 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!

Well if that's the goal, then hopefully there's going to be more interesting things than being on my podcast! Anyway, so what do you do these days? For work?

I went freelance a year ago, I wanted to get to be able to spend more time on self-study, pick projects that I thought were interesting. I wanted to pick projects that I thought I could really contribute to, mainly in terms of making sure they work for everybody. And so yeah, I took the plunge, registered with the Chamber of Commerce, and started looking for clients. And that actually wasn't so hard as I thought it would be. So now I have two really cool clients that I get to do accessibility work, for both. And yeah, so far, so good! And it's mainly frontend work, mixed with some backend and database work, where it needs to be done. But I'd say 90% is just frontend-related.

You are in the Netherlands, right?

Yes, happily below sea level.

Are these local clients?

No, that's actually a nice question. Both of them are international, so my main client, where I work four days a week, All Around the World, is composed of people from all over the world, as the name suggests. And the client I work Fridays, Tenon.io, is actually also international, but mainly Americans. So I tend to work from home, I'm a voluntary firefighter, and volunteer departments always have trouble finding people to be available during the day, when their pager goes. Speaking of which, I hope it won't go during this podcast, because I'll have to run out of the house. But I have a little desk there, I get to do work, and I'm the first guy in the truck when the pager goes, so these things actually combine very well at this moment.

So you're driving a firetruck?

No, no, that's usually somebody else. I tend to just wear gear, sit in the back of the truck, I'm a hose-dragger, as they call it.

Okay, and have you had a lot of fires that you had to put out?

Some decent ones. It's a small town, so not too many, but we've had some larger fires, some car accidents. Of course, you hope those never happen, but they do happen sometimes. And then your pager goes off and you race to the fire station and that's also, any testing thing where you go freelance, I always make sure to tell my clients, 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.

Yeah, well being a firefighter is, I think, a serious thing, right?

Well, it's either making sure the build doesn't fail or making sure the house doesn't burn down. You're fighting fires either way.

Okay, yeah! I'm not sure that's the same category, but anyway... Okay, so you do quite a lot of things with accessibility. Actually we started to talk about this podcast back when I interviewed Lucy about DictationBridge.

Right.

Let's get there, sorry I am more or less understanding that accessibility is meaning to make websites, basically, accessible for people with various disabilities. I can't say that word.

People with disabilities, yeah sure, that's a way to see it. It's mainly, for lack of a better word, proper accessibility. It's more about inclusive design and making sure that when you build something, you build it in such a way that as many people as possible can use it. Not just people with disabilities. You kind of don't try to think about that. You know that phrase that they used to say on the internet? 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.

So I went to yet another Perl conference, in Romania this year, and I spoke on inclusive design, where I basically had a little Dancer application that showed side-by-side a git-diff and an original application that I took from the web, a little to-do JavaScript application. And I would show, with small changes, how I would make it a bit more accessible with each change, showing which code I changed, what the difference was from the old version to the new version, now it became easier to use.

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.

Yeah, so I think yes, there is a lot of educational area where we have to teach people, actually the attitude. But there are also various tools, for example, just after that conversation with Lucy , I already wanted to make sure that my website is working well, or better at least. So I tried to find all kinds of tools that could give me some kind of report and tell me how to improve things. Let's talk about a couple of these tools that you're using, or suggesting?

Okay, well there are some open source tools in that regard, actually. There's one I really like, it's called NoCoffee, it's a Chrome extension, and what it does is you can use it to overlay a filter on the website, so to show, to make it blurry, make it render as somebody would see it with different types of color-blindness. There is a vision condition where you have these little floaters in your vision, and it simulates that, so you get these little floaters on top of the page, and they tend to move a little bit. And I know, actually I'm cheating a bit, it's not really open source, but I know the author is open to making it open source and so I've contacted him and asked him, 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.

So you are saying that actually there is this tool that currently is not open source? There is a bug that you reported...?

Well, that's a good point. I haven't actually reported it, I've simply asked him, 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.

So the question, why would it be good for him, to open source? What is the value on open sourcing or what is the value for him not to open source it?

Well, I don't really see the value in not open sourcing it, unless there's something he desperately wants to keep secret. But I don't see the value in that. I think open sourcing it would only have benefits, because people can use his technology to maybe integrate it in their tools and that would just create better accessibility tools. Or they could add their own filters to his extension, and I don't really see a...the only negative aspect I could see is then it becomes a community effort, and that maybe brings in a bunch of social collaboration that needs to be managed. But I don't think that that's not necessarily a problem. If it becomes a problem, deal with it. I mean, geez, he won't have to do it all by himself, for one. Because I can still tell him, 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...

So what other tools do you suggest?

If you're testing accessibility, and as I said earlier, it's not about checking off the boxes. It's about proper testing, so you spoke to Lucy, so you're familiar with the concept of a screen reader?

Yeah.

So for the audience, it's technology that reads out a page, or your desktop. So there are a bunch of closed one, for example MacOS comes with a VoiceOver, which I use a lot to test webpage accessibility. And on Windows, there is, amongst others, like JAWS, which is really, really, really expensive, thousands of dollars (note: this depends on your local Optelec dealer. See the pricing page).

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.

So what's easy for them, for blind people, it's hard for people who can see, because they are depending on the newlines more.

Yeah, the visual structure, we're really used to in our life. You know, there are whole debates on where your brackets should be, but yeah who cares, because it's interpreted differently that way by them. So there's also contributions from other people when it comes to translations. Which is just made so much easier, because you can just use something like GitHub to issue your own pull-request and collaborate and, I mean I know, they're just absolutely swamped doing so much stuff, so making it possible for other people to contribute just really helps everybody.

You mentioned the W3 validator and HTML5 validator, they are...

Yeah, but did you know, the original W3 validator is written in Perl?

Oh, yeah, I think I know... it still is?

It still is, yeah, I actually went through a bit of the code. It's a bit older but hey, the thing still works. So that's Perl you know, it's just keeping the web working behind the scenes. So the older HTML DTD validators are written in Perl. So that's at validator.w3.org.

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.

It won't check any of [garbled] for example, at least I don't think it checks the state of ARIA attributes, for accessibility and whether you're using those right. So there are libraries for that, that help. There is, I think the Google Chrome Accessibility Toolkit is on GitHub, which is a JavaScript library that you can use to query the DOM and run checks on it.

But there's also a toolkit that's make by Deque Systems, which is an accessibility company, they do mostly consultancy around accessibility work. But they also have something called the aXe, and it's the open source accessibility engine, which basically is a whole bunch of JavaScript validation rules. 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. Or, You're starting with an h2 heading and you actually don't have an h1 heading. Or, 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.

So I have a different question then, or maybe it's related. So people who don't know much about accessibility, like myself, but they have a website. They're not big corporations, they can't afford to hire a company providing this kind of service, how can we learn about accessibility? Is there some kind of a group, where I could ask people to take a look at my website and they would point out a couple of things maybe, or give directions? If people can go to a meetup where they meet you, and hear a presentation, that's great. But most of the people are not close enough to where you live.

Right, well there are various accessibility meetups around the world. But there are, there's the WebAIM mailing list, so there's the Web Accessibility Initiative (note: Web Accessibility In Mind), on that mailing list anyone can just ask questions there. There are various forums, there's of course, forums like SitePoint, they're not accessibility-specific, but you can ask your questions there.

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.

Okay, I think we are getting really close to the time when we have to finish this conversation.

Already, huh?

Yeah, time flies very fast when you enjoy yourselves. So any shout out that you would like to say to people? Anything that you haven't mentioned that you really want to?

Oh boy, that's difficult. Shout outs, no I don't want to play favoritism, I think...just, you know, the accessibility community and the awesome stuff a lot of people are doing. A lot of them in their own free time, to make sure that, making the web work for everybody just becomes easier every day.

Yeah, that's a very good call. So thank you very much for coming on the show and spending the time. And I hope that we'll be able to get sites more accessible and we can talk later on, on even more about this, because I think it's a very important subject.

Awesome, well if you ever have questions, just hit me up, and...thanks for letting me ramble.

Don't worry, I will. Bye bye.

All right, bye bye.