20minJS

Episode 10 - Accessibility in Web Applications with Graham Ritchie

May 11, 2022 OpenReplay Season 1 Episode 10
20minJS
Episode 10 - Accessibility in Web Applications with Graham Ritchie
Show Notes Transcript Chapter Markers

In this episode I discuss with Graham what accessibility is and how it impacts the web industry. The types of problems that accessibility tries to solve and how big of an impact it could have in your application if you were to actually pay attention to it during development.

Don't miss this episode, it's filled with interesting information and you're getting it directly from one of the experts!

Get in touch with Graham

Graham's Favorite Tools


Review Us!
Don't forget to leave a review of the episode or the entire podcast on Podchasers!

Meet our host, OpenReplay:
OpenReplay is an open-source session replay suite, built for developers and self-hosted for full control over your customer data. If you're looking for a way to understand how your users interact with your application, check out OpenReplay.

Graham Ritchie:

This year, 97%, more or less of homepages of websites have accessibility areas on them and the Aboriginal.

Fernando Doglio:

Hey, it's me again. Another week, another episode. This is episode number 10, of 20Min JavaScript where, where we discuss everything, JavaScript related. As always. This episode is hosted by OpenReplay and open source, session replay suite for developers. Stop guessing your production issues and check out OpenReplay. I'm Fernando Doglio your, your host on your podcast, demigod for the next 20 or so minutes. And today we're going to be talking about accessibility in web applications with Graham Ritchie. He's an accessibility consultant and head of marketing for daily.dev. So Graham welcome. Thank you for being here and please introduce yourself.

Graham Ritchie:

Yeah, thank you very much for having me. Uh, so yeah. Hi, I'm Graham. I specialize in accessibility and, uh, load load speed performance. Are my two sorts of things that I like to get involved in. Um, I have my own business where I do a lot of accessibility consulting and performance consulting, et cetera. And then recently I've started working at daily.dev. Um, and it's a bit of a switch because I got hired as a content writer. But I'm slowly moving into the position of sort of setting up a marketing department for them. So, uh, it's quite an interesting change and, um, yeah, really excited to be there, to be honest with you. I really enjoy it there.

Fernando Doglio:

Sounds interesting. All right. Thank you for being here today. We're going to be talking about accessibility with you because, uh, from what I've seen, at least in what I've, uh, experienced, you're one of the only I've managed to find the actively, uh, promote and actively write and create content around accessibility. So, uh, I wanted to get you in the, in the podcast and try to cover that. So, uh, for those who don't know me included, can you kind of explain what is accessibility? What do you mean when you talk about accessibility and who is it affecting, especially why as a developers, should we care about it?

Graham Ritchie:

Okay. Um, so accessibility means making a website or a physical location, but we'll talk about websites obviously, um, accessible for people with disabilities. So that means making them as usable as possible for people who might use, for example, a screen reader, which is a piece of software that will read the webpage out to someone who's blind. For example, Um, now it basically boils down to, um, structuring HTML correctly, color contrast, all sorts of different things, depending on what disability we're talking about, but effectively it's just standards and how you actually structure a page and how you actually build a page can affect greatly how someone with a disability can interact with that page. Um, if they require for you to, um, you know, consider their need space.

Fernando Doglio:

All right. Interesting. And, and, um, can you think of any examples of, uh, these cases where that we've seen or that we interact with everyday that we don't realize.

Graham Ritchie:

Yeah. Uh, I mean, how about the keyboard right in front of you, if you currently set the computer that was designed for someone who's blind and was, uh, couldn't actually, uh, write by hand. Uh, so I think it was Peligrino III or something like that. Um, invented the first sort of concept of a typewriter. And, uh, here we are now, uh, or how about the electric toothbrush? Uh, it was designed for people with low grip strength and mobility. Or SMS text messaging for those of you were old enough to remember that before we had WhatsApp that was designed for people who were deaf, uh, I could go on, on and on. I mean, even, uh, Vinton Cerf, um, one of the, the founding fathers of the internet sort of thing, uh, he was hard of hearing and the story goes, I've not got any sources for this, but the story goes that, uh, he wanted shared documents because he struggled to speak on the phone. So the internet was born. So, yeah, a lot of things that are designed for people with disabilities filter down and make everyone's lives easier.

Fernando Doglio:

All right. And, and accessibility might be widespread, like you said. I mean, in, in every, in every, in every aspect of our lives, we deal with things that were designed because of accessibility apparently, but it doesn't feel like it is a widespread practice. Just put it that way, because I mean, I've been around 20 years, uh, in, in the industry and it's not like I had to deal with this and maybe it's, you know, a terrible mistake on my part. Definitely it is. But the point is I never, I've never seen it as, uh, working as a consultant, uh, as a hard requirement on any of the projects I worked on. My, my question here is how widespread is it actually the, the, the, the actual practice of, uh, accessibility within the software development. Um, and, um, how standard is it? Uh, maybe it's, you know, um, uh, I'm struggling to see it, but maybe it's just my point of view and in it's actually quite widespread. So that's kind of why I'm asking.

Graham Ritchie:

So, I suppose there's two aspects to that. There's the, um, how widespread is it at the moment? How many people actually make accessible products, but there's how many people need it, which I'm sure we'll cover later. Yeah. Um, so let's cover that how widespread it is at the moment and sadly, not very, um, there's a company called WebAIM who do an analysis of the top million webpages every year. Um, and this year, 97%, more or less of homepages of websites have accessibility errors on them. And the average number of errors these 50, give you an idea. So, uh, yeah, it's about one in every six elements on a page has an accessibility error. So the, the sub part is, um, like you said, it doesn't come up in conversation. It's improving massively. It's now something where the conversations are being had and awareness is there. But for years we sort of just swept it under the carpet. And it's, um, the last big frontier in sort of web development, as far as I'm concerned, it's the bit that not enough people are talking about, and it's interesting and exciting, and you get to help people and reach more people, which is what we're here for basically as developers, or at least in my eyes.

Fernando Doglio:

Absolutely. Absolutely. And what, what, what are some of these errors, uh, that there are so common.

Graham Ritchie:

Some of the most common ones are simple things like ALT attributes, on images.. Obviously if you're, if you're blind, you can't see the image. I mean, that is an oversimplification. There are very, uh, there are various levels of blindness, but if you are totally blind, you can't see that image. You're relying on a screen reader to read the image to you. If someone just doesn't put an alt text on there or an ALT attribute or description for the image, you've no idea what the image is for. And a lot of times the images add a lot of impact to a page. Um, social media is a prime example, you know, uh, even I a whole man's up occasionally forget to put an alt attribute on an image on social media. And it's just, uh, it's exclusionary, you know, and it takes all of 30 seconds to do it. So, uh, that's the big one. Uh, and then you see things like no focusing indicators. So someone has mobility issues and relies on the keyboard rather than a mouse. That will be tabbing around a page. And they've no idea what they've currently got focused. Cause there's no focus indicators because we like to switch them off for no reason, because they're ugly. If you click on a button and they pop pop apparently, uh, and there are ways to fix it. They're very simple. So those are the two sort of big ones. And then you've got color contrast, which is a little more complicated, but it's still a simple concept.

Fernando Doglio:

Okay. Okay. Yeah, definitely, definitely sounds familiar. And it's like you said, I mean, these are things that, uh, If you're a web developer, you deal with everyday it's just, you just decide to either ignore them or go the other way.

Graham Ritchie:

Yeah. It's not even, it's not even ignoring them. I think the problem starts earlier than that, which is you don't get taught about it in the first place. You're not aware of the problem. I don't think anyone is deliberately going, oh, I'm going to remove focus indicators and make it hard work for people who rely on the keyboard it's that they aren't aware of the impact of what they are doing. Um, so that's where the problem starts. If you asked me. Yeah.

Fernando Doglio:

All right. And I guess kind of, you already answered that question, but these that you mentioned are definitely things that are part of the everyday coding life, essentially about whether you're, but, do we have like uh, you know, frameworks like react or VUE or, or libraries that we use everyday, or even the IDE, um, that already provide these tools or the, the tools or the indicators or the checks or whatever that we need to make these, to make sure that we're creating something accessible and we're just not using them. Or do we have to like reach out for something specific to make sure that, uh, what we're doing is accessible.

Graham Ritchie:

Normally you would need a plugin or something like that. If you want to have like, linting on your code, for example, to pick up accessibility errors early, but there is one tool that nearly everyone will be using, which is developer tools on, on Chrome or Firefox, et cetera. There is a wealth of information in there from an accessibility standpoint. So using Chrome and exam as an example, um, if you right click and inspect an element and you go see the color CSS property, you can click a little square and you get a nice little chart and graph with two lines on it. And the lines represent where the color contrast requirements are based on the background that that element is on. So you can just literally move the slider up a little bit above these lines. And you've met your contrast requirements. Um, yeah, again, in, in developer tools, if you're on the elements tab, um, there is a whole accessibility tab. Top right panel. I never know what to call the panels. Unfortunately, I'm useless, but top right, you can scroll across, uh, there's the accessibility tab there. And that will give you what's called the accessibility tree, which is basically what a screen reader or any assistive technology will use to decide what to say out and how to represent. And you can learn loads of stuff from that. Uh, and then finally, um, download the in the bottom drawer yet. Again, don't know what to call that panel on developer tools. If you click the three dots, you can click on the rendering tab and turn that on. And that gives you loads of stuff like checks for reduced motion and see if your app behaves correctly. So if you someone indicates they prefer reduced motion, um, your app should like limit animations effectively, um, prefers color scheme, high contrast. See if they actually, uh, behaves well with up and even simulate different types of colorblindness right near the bottom. There is actually an option to try different types of colorblindness and see if your app is relying on color too much to convey them for me. Uh, and even see what it looks like with blurry vision so that you can get a feel for if your font size is too small. So in terms of what nearly every developer is using everyday, I think that's the best example. Um, and then obviously a lot of it, unfortunately yet again, is you require plugins and tools to do some of the work. Um, but it's quite easy to use, right?

Fernando Doglio:

Well, well, well, but, uh, I mean, I mean, yeah, definitely. Uh, the tools will probably give you even more information, but oh, all that you said there, just with Chrome , I didn't know that was there at all. And I'm sure many other developers don't either. That's definitely. Definitely interesting in something. I'll be checking, checking out.

Graham Ritchie:

That is the biggest stumbling block is the awareness, you know, that's, that's the thing. Once you're aware a lot of this stuff isn't complicated. Uh, but we'll yeah, we'll probably come to that. You know, I, I could probably waffle on for hours about accessibility and I'm, uh, I'll let, I'll let you guide the conversation. Otherwise I'll just keep talking and people we'll get bored..

Fernando Doglio:

I don't think so. Uh, this is definitely, this is such an interesting topic and I hate that it gets so ignored so much. I mean, definitely, uh, you know, with the tools at our disposal. I mean, it's not like we have to go out of reach to, to do things accessible or at least a little bit more accessible. I mean.

Graham Ritchie:

Little improvements all the time.

Fernando Doglio:

Exactly. So, uh, again, I think you already kind of said this, but, uh, what do you think are the top three reasons why people just ignore this? Uh, is it convenience? Is it just lack of information?

Graham Ritchie:

I think the number one thing is awareness. Yeah. Again, I had been a developer for probably seven, eight years before I stumbled into accessibility. So that's how rarely it was talked about. Like I said, it is improving, but it's still very much a fringe topic that people talk about. Um, and I stumbled into it because I I'd hurt my wrist and was struggling to use the keyboard discovered accessibility and ever since I've just fallen into this world of amazing things. And it's really interesting to me. Um, but that's number one. Like if you do a coding boot camp, they might touch on accessibility for about five minutes, but they don't drill home. You know how many people it affects them, why you actually need to do this and how it makes your life easier as a developer. That's the bit that I always try and push home to people. So I think that's number one. Problem is awareness. And then the second problem is. We've made it hard to actually get into it. Um, like the, the rules that you use to check accessibility is something called WCAG a hundred ways that people, um, pronounce it, W C A G. So those are the guides. The problem is they are written in such a way that they are very hard to consume and we're all busy. And I think that puts a lot of people off the line. Oh, color contrast. And then they go and read the guidelines. Okay. I have no idea what that's telling me to do. So I think it's that. Uh, and then the last one is tutorials that are out there. You know, you learn from a tutorial, you then think that you've learned it the right way. So you create the same tutorial. Then we have this continuing pattern of. Terrible accessibility practices and nobody corrects them sort of things. So it just continues that way. It's just legacy, basically a prime example, being people who are using anchors as buttons, we haven't needed to do that for 15 years since HTML five, but that pattern is still everywhere. Um, use a button for a button. It makes everything easier for you and for people using your application. So, yeah, like I said, don't get me on my high horse, but I think those are the top three things that the other big problem, basically.

Fernando Doglio:

All right. I guess, uh, the, the dev tools for also cover this, but are there any other tools that you rather use to audit a website or a web application that you're building, uh, to make sure it covers everything or someone else's building and you want to make sure that everything, uh, accessibility wide wise is called covered. Would you manually check it. Or do you have a preferred tool to to audit it.

Graham Ritchie:

Yeah. So in terms of tools, there are, there are lots of great tools, but I think we'll start at the other side of the problem, which is tools cover about 35 to 45%, maybe 50% of accessibility errors. A lot of it needs to be knowledge and manually checked, and that's another sort of barrier that we have. Um, however, if you can fix the 35 to 45% of accessibility errors that we can pick up automatically. That is probably 60 to 65% of all accessibility problems, ironically. So there are two tools for a beginning of that. I would definitely recommend the both plugins for a browser. Uh, there's Axe by Deque systems, D E Q U E. Uh, so apologies if I said that wrong.. I always have arguments on how you say that as well. Uh, That's literally a plugin for the browser. You run it on your page and it will give you a list of accessibility errors and some reasonably good information about why it's a problem where you can get more guidance and a tiny bit on how to fix it. And then there's the slightly more advanced form, which is exactly the same sorts of tool, which is accessibility insights from Microsoft of all people. Um, we all like to hate on Microsoft, but you know, this is probably. One of the best tools I've come across. And that not only does all the automated tests, but it can guide you through the manual tests. So things like checking the tab order of the page and checking for keyboard traps, which is if you end up in a modal and can't get out of it with like the escape key or your keyboard at all, because you've decided to use the close button is you know, a DIV, so you can't actually focus it that's a keyboard trap. You can't get out to that. You stuck a, it helps you check for those things. So accessibility insights from Microsoft is probably one of, if not the best sort of checking tools you can get. And then there are loads of linters depending on which language you are, you can literally just do a Google search for accessibility linter React, to accessibility linter Vue, and it will correct a lot of the low level stuff in your actual code as early as it can. Um, so those are the ones I recommend, but like I said, unfortunately, you do need someone with the knowledge or you need the knowledge yourself to do a lot of the manual checks. Um, but yeah, again, uh, if you look at the, uh, a11y accessibility project, um, they have a good checklist you can follow. So you can literally put a11y which is a newer name for a new name. Can never say that word correctly, uh, for accessible. Um, you can go on there. They've got a checklist of things to check and it talks you through it at a very low level of basics and you'll probably catch most of yourself. Um, so yeah, those are the two sort of best ways that you can sort of get into accessibility and stuff.

Fernando Doglio:

All right. So the tools cover like 50% tops by like you said, I mean, there's a lot of manual checking because there's definitely nothing you can do about, uh, to automate out like a keyboard, detecting a keyboard trap. What will be the number one, uh, resource for learning this, because if you, if you say the standards are hard to understand, are there any learning resources out there that, that make it, make them easier that you trust as well?

Graham Ritchie:

I mean, like I said, Accessibility project a11y project is a good resource. Um, but sadly, we are lucking this Sarah, I'm going to butcher her name, Sarah Sweden, uh, on Twitter. She's got a blog. Um, she writes brilliant in depth explanations on things that make it very easy to understand. But yet again, if you're a beginner, there might be a little. Overwhelming sort of thing. So we are missing that beginner a resource, and it is something that, um, I am working on in the background that I'm trying to actually pull together, but I've never found a really good introduction to accessibility that doesn't start with. What is accessibility? Why should you care? Because a lot of people have read that stuff. If they're already thinking about it, it's literally here is step one. Here is how you test this thing. Here is step two um, so yeah, it's, it's an area where there's lots of opportunities for someone who's in the space to create the ultimate course. There's a couple of Udemy, courses that are okay, but none that I would truly recommend, but worth a watch sort of thing. But yeah, there's a big gap there and that's yet again, half of the problem. Yeah. Um, so I'd suggest asking questions on stack overflow. You'll nearly always see me pop up and answer some questions there if you get stuck or aren't sure, but yeah, when we need it to go back a level, we need, we need courses that are teaching you how to get into development to actually raise the flag in the first place. Because at that point it's easy to start finding the things you need. Once you understand the basic.

Fernando Doglio:

Okay. And do you have an idea of, I'm trying to, to understand, uh, and without sounding unsensitive to, uh, to everyone who benefits from accessibility, but if it's a matter of, a lot of companies. Even, you know, at a high level, just ignoring this practice because it doesn't really provide a big return on investment. Put it that way. You know, the amount of time you spend working on adding or fixing accessibility versus the amount of users that, that will benefit from it. So this is completely cold harsh numbers and I don't feel that way. I don't think that way, but I'm thinking that having been part of big corporations, big consulting corporations, and that has never come up in my experience. So I'm wondering. That might be the reason. So do you know or have any ideas or have read like recent studies regarding the percentage of the user base that benefit from this practice?

Graham Ritchie:

Yeah. So there's two elements to unpack there. Um, the first is our current user base doesn't have any disabilities. Well, a how do you know. Yeah, because there's no way of actually measuring that and knowing that, and secondly, if your product isn't accessible then the people with disabilities will be elsewhere because they can't use your product. So it's, it's like the survivorship bias of like, when they used to check the planes, when they came back from war and they were like seeing where all the bullet holes were like, oh, okay, this is things we need to enforce. It's like, no, you need to know which planes have actually crashed. You know, that's where, you know, where the. Um, so you never get that bit of information. Um, so that's one aspect of it. The second aspect that you mentioned was obviously where's the benefit to a business. Um, so to run a few quick numbers, um, the world health organization says one to 2 billion people with vision impairments in the world. So I always think that number is a little high or there might be, you know, If that's true, then that's like one in five people basically. Um, but the, on terms of what, what information we do have there's around 50 million people who have total blindness in the world, probably about 250 million have severe vision loss to the stage where they may as well be completely blind. So that's about three to 4% of people in the world. Uh, around five to 10% of people in the world are deaf or hard of hearing. So deaf with a capital D or a small D uh, Overall the numbers add up to about one in six, one in seven people have some form of a disability. So when you start thinking of it, that way, it's the largest minority. That's the way I always look at it. It's like, yes, there are many different needs and stuff, but overall it's the largest minority that we're ignoring. You know, we, we, we're making progress on one of the things and we're still a long way behind on disabled rights. So to me, that's opportunity. I'm not one of the fluffy people. Um, and I often get shouted down for not being fluffy about it, but I, I, I approached from a business perspective, the, there is a large audience say 10% of your user base that you're probably currently not servicing. Um, probably none of the competitors are, you know, people with disabilities are choosing the sort of lesser evil sort of thing. Nearly everything's inaccessible. If you're the first company to be accessible in your space and you can make some noise about it, then the disabled community is a close-knit community. So let's say you make it completely accessible for people who are blind. Blind people have a blind friends and they will tell other blind friends and they will come use your product. So to me, it's, it's a business sense thing. You know, there's, there's loads of benefit I can add to the world, but I'm just saying to people who run a business who are developing products, do it, do it. Now there's a massive opportunity to kick some ass. Pardon my French here and gather a huge user base that nobody is looking after. So that's my perspective on it anyway.

Fernando Doglio:

Absolutely. Yeah. Yeah. Last question. And I think I know the answer, but where do you draw the limit when you start adding or fixing accessibility you yourself and what do you recommend others? Because I want to know if that's the same number, but do you just go all in and fix every single damn thing about accessibility that you can think of? Or do you say, well, you know, this is enough. I mean, this is enough that, uh, I, I don't know. I spent three, three days. It's accessible enough for, for other people. So I'll just stop here.

Graham Ritchie:

It's one of those very tough questions to answer that because enough would be when it is perfectly accessible, that would be the dream. Right? However, you've got to be a realist about these things. So the way I approach it with businesses and with developers is. We, we start with something new that you're developing, cause it's a lot more expensive and a lot more time consuming to fix an old problem than it is to set the groundwork at day one and choose the correct sort of elements and you know, pattern that we're going to use and everything else that it is to try and back fix something. So I say, you know, day one today, you wanted me to come in and have a look and say, right, what should we fix here? Unless there's some really low hanging fruit, forget everything you've built before. Let's look at what you're building next. What are you currently working on? And then try for. So there's three levels of a work rating. There's A, AA and AAA. AA is like the international. This is where the legal standing is because that's the bit that other people don't understand is your site in nearly every country, legally has to be accessible. We just don't enforce that yet again, although America is doing a good job at. Uh, you know, raising the lawsuits at the moment and struggling it's that way, shall we say? So there's three levels and ideally we should all get to AAA, but there's, you know, there is a balance there, and it's a sad thing to say because I would love for every website to be perfect, but I think you have to try and go, right? What can we achieve within our current budget? I wrote, I used the 10% rule. You know, if it's going to cost 10% more to make it accessible, how far can we, can we reach that? Um, because it will pay for itself at that point. And yet again, we have to go down to brass tax at the end of the day, in terms of when it's, when do you stop? Uh, I think that's the same as anything. You know, if you're designing a particular widget for a page, when do you stop? You know, can you, could you add this extra feature? You, you start having to weigh up hours versus reward. Um, and a lot of the time and accessibility, the beauty is if you do start at day one, You won't have to do that, uh, weighing up, um, because if you design from accessible to, they want, it actually becomes quite easy. If anything, it makes the process easier overall. Uh, but the will be certain things that will just be unsolvable with current technology or current finances. And that's where you draw the line, you know, um, at the end of the day, even if you're making the effort, you are still better than 97.4% of all the other websites out there. You know, at the end of the day, that's what people appreciate. And like I said, it's, it's a gradual process. Step by step by step. We'll eventually get someone to have the first fully accessible website, but I don't think one actually exists. We've got some very good ones, but I don't think there's a perfect website because there's so many ways people interact with a computer. Um, we didn't even talk about unite sip puff, which is the last one of the things that really interested me about accessibility. People who have a straw and they either suck on it or blow on it. And that sends commands to a computer to access a website. How do you make something accessible for that? You know, it's kind of, there are limitations of the software that powers that. So there's no such thing as perfect. Put the effort in, and like, say, get someone involved who knows about accessibility, who can guide you to make the right decisions at day one. And you'll, you'll get 95%, 99% of the way there. And I think that currently is where we need to be. Cool. All

Fernando Doglio:

right. Thank you for that. And that's it for the time we had for accessibility. I'll now ask you three questions that I ask every guest. Uh, just answer what's whatever's at the top of your head. All right. So first of all, what's the best advice you ever received?.

Graham Ritchie:

The best advice I ever received was, uh, you have two eyes, two ears, one mouth use them in proportion. Unfortunately, I've got to admit it is advice. I very much struggle to follow, but it certainly is the best advice you should absorb information more than you start talking out really um, which is ironic when I'm on a podcast, but you know, that to me is a brilliant piece of advice. There are too many people talk without thinking, and it's certainly something I always try to be better at, but I do fail miserably. It's built into my genes that I just talk without thinking I try to improve, but I fail.

Fernando Doglio:

It's a great piece of advice. Amazing. All right. Um, what's the most exciting project you worked on?

Graham Ritchie:

So. Right. So this there's two projects, really? Sorry, just to, to change that. So one was, uh, I worked with a certain, uh, disliked fracking company. Who's well known around the world. Um, I built a piece of software that was monitoring the wastewater on a site. To ensure that the pH levels, there were no pollutants that it wasn't frozen over, cause that can cause problems, et cetera, to ensure that it didn't, um, spill out into the environment. Um, that was fascinating because we were having to work with sites where the only way we could communicate with them was, um, via SIM card on 2 G. So we had to send text messages, uh, and building a system around that that was robust and would work and had four bucks that everything was really, really interesting. Um, and then the other one, I, like I said, I'm not blowing smoke up. My current employers, uh, rear end daily.dev is super interesting. I wish I could tell you some of the things that are on the roadmap, but, uh, I can't yet, but seeing where they want to take it from what is effectively a, an aggregation feed and albeit a very good one. Is super exciting and the people there and the team just th there's so much knowledge I can gain from the people who are there. It's a level up from most of the people I've worked with in the past. So, uh, I'm super excited to see where that goes. And, um, like I said, hopefully since I'm going to be part of the marketing team, be the one to tell you all about it when I'm allowed to.

Fernando Doglio:

Definitely looking forward to that. Um, last question. What is one thing you wish you knew before you started coding?

Graham Ritchie:

I'm going to sound like a broken record here, but accessibility would have been the thing that I would like to have known about from day one. It certainly changed the way that I approach things. So I would obviously over-engineer the living daylights out of stuff when I was young and trying to be, you know, top of the world and amazing. And it just changed your perspective too. You know what sometimes simpler is better. Um, there's a lot of native stuff. Does it work for you? I could have saved myself hours of hassle and headaches and relearning things, everything. So, yeah, I know that seems like a bit of a, a cop out answer, but yeah, I, I truly wish that would have been the thing I knew at day one, um, before learning an HTML or CSS, but especially HTML.

Fernando Doglio:

Do you think that, uh, back then. The, the state of HTML and CSS and Javascript, it was. Good enough to make it worth your while learning accessibility before coding, because I mean, I, I remember H the kind of HTML, I, I picked up when I started coding and it wasn't like they one we're using today, there, there are a lot more elements right now. And a lot of properties that help you in that regard that were not even part of the language.

Graham Ritchie:

So, and that is a valid point. And thank you for pointing out how old I am to everyone that I remember the days of HTML4 and next to XHTML I was hoping people would think I was younger, but you know, you've ruined. Um, yeah, no. Okay. So that is probably a valid point. So when I started you're right, it probably wouldn't have been as beneficial. Uh, however, it's still probably knowing it, even if I wasn't in depth in, it would have been when HTML five came in because we are talking nearly 15 years ago would have immediately made me more interested because I just stayed with DIV soup back then. Um, but yeah, I mean, my first website I built was built in tables so, you know, I, I was that bad, a developer, we built things with tables, which from an accessibility perspective is ah, horrendous. Um, but yeah, you're right. The technology has moved on and perhaps I'm looking back with rose tinted glasses. So I suppose a better answer would have been perfection isn't what you need to aim for every time, because I think that held me back as well. I wanted to understand everything deeply at the beginning. And if you're a new developer, you need to understand concepts, not detail. You can look something up if you understand the concept and what you're looking for half the time. I didn't know what I was looking for. Oh, yeah. I've changed my answer to that. Cause you.

Fernando Doglio:

It wasn't right to change your answer. It was just trying to have a conversation, that's all.

Graham Ritchie:

You're very persuasive. Like

Fernando Doglio:

I can see that. All right. Okay. Um, that's it that's really all the time. we had, we actually went over a bit but that's okay. This was a very interesting topic. Thank you for, for covering so much. And I I'm sure, uh, if we had the time you still had you'll still have a lot of, a lot of things to say. So, um, hopefully we can get you back for, uh, for a second, second round, uh, at this topic more in depth, but in the meantime, uh, can you please tell our audience where they can find you, uh, where you're online and, uh, all those links we'll just add on the show notes anyway.

Graham Ritchie:

Yeah. So, um, easiest way, if you want to grab me is on Twitter, uh, at, @inHuOfficial I N H U official, or I've just set up a new account, cause it didn't really work for daily.dev in that one. So @grahamTheDev, uh, so that's a brand new account, so you can be one of my first followers there, if you want. Yeah, that's good too. I probably need to follow you back on that one yet though. Cause I don't use it much. Um, and then I write on Dev.to. So yet again, under I N H U official in inHuOfficial, you can find loads of stuff on there. I do have a particular piece, which is 101 accessibility tips, which is 16 and a half thousand words on accessibility. Designed as a reference piece not something you sit and read. But that's my sort of favorite piece I've written. I'd love for you to read it. If you try to understand the basics of accessibility, it covers so many different parts, and then you can always find me on LinkedIn/in/graham-ritchie/. Uh, oh, I'm finally, there's the 4C community on discord. So if you look for the 4C community, I'm an active member there, uh, sort of content creators, but yeah, again, you can always reach out to me on that one. So those are all the places you can find me. Awesome.

Fernando Doglio:

All right. We'll just link a link to all of those on the show notes so everyone can come find you.

Graham Ritchie:

Um, and that's it again, thank you so much for coming in and discussing this and that's it. Uh, thank you so much. It was a super interesting and uh, some great questions there. And, uh, yeah, I, I feel like I, I perhaps expanded too much on stuff because like you said, we went over time. So next time I'll try and be more succinct to the event if you do ask me back.

Fernando Doglio:

Don't worry about it. It was really interesting. So thank you. All right, bye everyone. See you on the next one.

Graham Ritchie:

Thank you very much. See you.

Meet Graham
What is accessibility?
Why isn't accessiblity a common practice in software development?
What are the most common accessibility problems?
Are there tools that we use every day that can help with accessibility?
What tools can be used to check the accessibility of an app?
Where can you learn about accessibility?
Why aren't corps more interested in accessibility?
When can you say "enough" when adding accessibility to a web app?
What's the best advice ever received?
The most interesting project
One thing he regrets not knowing before starting to code
Where can people find him?