On-Demand: Develop for Accessibility

Transcript for Accessible Development Panel Discussion

OPENING

Lori Litz

Hi, everyone. Welcome back for day two of Design. Develop, and Deploy for Accessibility. My name is Lori. I'm the Director of Conferences here at Accessibility.com and we are so pleased to have you here for day two, Develop for Accessibility. So what do you do when you develop for accessibility? Well, we've got three amazing experts in the industry to put on a great discussion today on what to do, what to take from your design team, and how to get it developed.

So we welcome back again, Mike Paciello from WEBAble, and his two friends, Gerard Cohen and Joe Dolson, who have lots of experience in developing for accessibility. Today's event is recorded, so if you have to jump off early, no, nothing to worry about. We will send out an email this evening once everything's been loaded on how to access today's event, including the transcripts and the event’s closed captioning.

So you will have that. As we go along through today's event, please do not hesitate to use the chat button to chat amongst one another. If you have any questions for the panelists, you can go ahead and type those into the Q&A section. If they do not get to your question today, I will send those questions to them and see if we can't get some written answers that we'll post back on the event site.

And without further ado, let's get right into day two, Develop for Accessibility with Mike Paciello, Gerard Cohen, and Joe Dolson.

PANEL DISCUSSION

Mike Paciello

Hi there. This is Mike Paciello and we're here today with some of our colleagues and friends of mine, Joe Dolson and Gerard Cohen. This is the second in a three part series, Design, Develop and Deploy for Accessibility. So I'm really happy to be here with with some of my good friends, Gerard and Joe. We work together very closely over these last few years.

So Joe, do you mind introducing yourself to the audience?

Joe Dolson

Absolutely. So I'm Joe Dolson. I'm an accessibility consultant and and developer. I am a core committer to the WordPress project. And so I've been a lead member of the accessibility process for WordPress for a number of years, and I am really happy to be here with you, Mike.

Mike Paciello

Thank you. Gerard. Where are you from? Where you be?

Gerard Cohen

Thanks, Mike. Uh, honored to be here with both of you. I'm Gerard Cohen. I am currently the Engineering Manager at Atlassian for the Design System, focused on accessibility. Previously, I was the engineering manager for the accessibility team at Twitter, and I've been working on accessibility for about 10, 15 years maybe now. It seems like forever. But yeah, very happy to be here.

Mike Paciello

You're so young, you're so young. I’m working on year 40..

Gerard Cohen

I can only.

I can only hope to to last that long.

Mike Paciello

Yeah, well, you know, today's topic, guys, it's. I'm really glad to have both of you here is about developing for accessibility. And and I think there are a lot of challenges, as we all know in the engineering lifecycle. You know, the various stages that we come across. But I, I've often found that the two hardest include this one. And that is developing for accessibility.

If I had a nickel, maybe even a penny for for the bad advice and bad direction that is often either deployed or written about or done, you know, I could be a millionaire just, just on that. So I really want to dive into what that engineering lifecycle looks like and how you as developer development leaders, you know, how you see things, how you make things work within your organizations.

Now I know, Joe Dolson, you kind of work out of your own shop in with, with, with, with your work. And of course you've done a lot of work for, for my own company at WEBAble. So Joe, just tell me, specifically, how do you move from, you know, from a design phase to to development? You know, when do you know you're ready to get started?

How do you prepare and how do you get engaged with your clients?

Joe Dolson

Well, I usually start it. It depends so much on the development environment I'm working in. So there's everything from a case where I'm taking designs from a designer and I will be simply reviewing those designs and pushing back on major gaps, you know, color contrast issues that just need to be dealt with before any of this can go to approval by the client.

And then if I'm developing myself, once all of the visual problems are resolved, I can go to a go and get that approval and move towards development right away. But everything changes a lot when I'm working with a development team, when I'm moving in a consulting role, because in that case I really want to get a lot more annotation into that design to make sure things are documented.

Like what is the animation behavior of a component? Or what what element here is actually the label and what is associated via say, ARIA described by. Because there's a lot of available tools now for annotating designs to make these kinds of relationships more clear to the developers who are going to receive them. Knowing... if I know the development team and I know their level of security, sometimes those stages can be a little bit more relaxed. But frequently it's always... I hesitate to I hesitate to say frequently. It is almost always better to just have everything documented if you can.

Mike Paciello

Right.

Joe Dolson

You never... I don't think there is a stage where a design becomes bulletproof. There's just not enough information in a design document by itself to be able to say to a developer, go to town, you can't possibly make a mistake. That's just not the reality. But knowing your developer, knowing you're development team, is a huge part of the issue.

Mike Paciello

Yeah, and I imagine, Joe, especially, you know, from from where you're coming from professionally, you're, you know, you're not working intrinsically like, like Gerard is. We’ll get to Gerard in just in just a minute. You know, you're working with people who probably aren't as familiar with what really needs to be done, even from a design standpoint, you'll never mind development where accessibility is concerned, right?

Because they just they just typically don't really think about all the nuances associated with the you know, with the usability and the user experience of a person with disabilities. So that makes it more challenging, as you know, as a subcontractor or coming in as you know, as as a third party here. Do you agree?

Joe Dolson

Absolutely. I work with a lot of small nonprofits, and so I'm working with a lot of people who have fabulous intentions and really want things to be done as well as possible, but also a very small budgets and are frequently working, you know, to a tight deadline with no, not a lot of systems in place. A lot of different part time contractors, part time content creators involved who are, need to be brought together so that everything can work.

And so it does require a lot of oversight. A lot of checking and making sure all of the T's have been crossed and I's have been dotted and not the reverse.

Mike Paciello

Yeah, Yeah, exactly. Now, now, Gerard, let's let's move over to you with that. You're with Atlassian now. You were at Twitter. We first met when you were at Wells Fargo. So you've got, from my standpoint, a wealth of, of developer’s knowledge. But again, you're now in a corporation. And so things work a little bit differently than than Joe does.

So can... talk us through the design to development phase from from your perspective and how that works.

Gerard Cohen

Yeah. So it's it's not I don't think it's too different from Joe's experience. The only difference is obviously the scope is a lot bigger as far as the type of people that I have to interact with and, and, you know, basically of impact versus as far as culture change. Right? You know, it's interesting because I think that this may be controversial, and I may be kicked out of certain engineering circles because of this, but I actually think accessibility is easier to do in waterfall like environments versus agile environments.

You know, having, having proper user research done ahead of time. Right? Proper business requirements ahead of time. Design, annotations, content, all this stuff handled ahead of time is really important because having to go back to those areas later on when when stuff has started to, you know, be codified via code, it's really, really time consuming and expensive to go back, to undo. And it’s probably one of the biggest reasons why, you know, in these in these larger companies it's really hard to to be accessible because a lot of times those people, the user research people, the designers, they've already dropped off the project and they have gone on to other things.

And it's really hard to get everyone back together again to reevaluate and readdress the problem. So that's kind of one of the challenges that I've had, you know, in my experiences.

Mike Paciello

Yeah, that's that’s... And I'm going to definitely come back to the waterfall versus agile development because, just my experience, I've had just the opposite experience. So I definitely want to tackle that. But that actually kind of takes us to to the next question, and I'll start with you, Gerard. What's your best advice for establishing a development process to check check points and milestones?

You know, as you're looking along your own developer continuum, how does that play out?

Gerard Cohen

Yeah, so the mantra that I've always had is early and often. You know, you want to you want to be thinking about accessibility as early as possible and you want to be thinking about it as often as possible. It's very easy to consider accessibility as something that's like extra or additional or on top of, but it really just needs to be in line with everything else that's being done.

So it's not some... You know, there's a thin balance that I try to make between establishing very separate procedures for accessibility, which is really important to keep things top of mind, but then also by merging them into the everyday process that everyone else is going through. Because if you if you again, if you consider something to be extra or on top of it's very easy to to, you know, dismiss when certain things happen, whether it's time or budget or that kind of stuff.

So if you if you just build it into the everyday process and you build that muscle of it's just part of everything that you do, then it makes it a lot easier.

Mike Paciello

Yeah, Yeah, that makes sense. Joe, what are your thoughts on that? And I should mention that even though Joe, most of your work is as a subcontractor, I mean you are intrinsically involved with WordPress, so it's not like that's, you're not involved in the organizational environment either.

Joe Dolson

Yeah. And the work I do with WordPress is a lot more like what Gerard is talking about because it is an enormous project and there are hundreds and hundreds of people working at it at all times. And that is an ongoing problem because one of the things about WordPress is we have this extremely strong commitment to backwards compatibility, which sometimes means you make a mistake and you release something that doesn't meet your standards.

You're committed to keeping that and you have to start to try and find workarounds to make things better. You know, the a good example of this is, is in the WordPress Media library. That whole system was initially built with not a lot of accessibility in mind. And it has been an incredibly challenging process to gradually build better accessibility into that system over time because it didn't happen from the beginning.

And this is... I at 100% agree, like this whole early and often approach is critical. I mean, you you can really get yourself in trouble by not exploring accessibility at the earliest possible stage. And that is a challenge sometimes because obviously, like the design process, it it frequently doesn't make a lot of sense for there to be a lot of code in the design process.

That's not always efficient. So there are things you simply can't test that way and then you need to move them into a stage where you can test them. But every test you can do, do it as soon as you can.

Mike Paciello

Yeah. So, you know, see that, when I hear both of you say early and often, I can't help but think of, of agile. At that, at that point we're talking about a continuous development, continuous improvement. So prove me wrong, Gerard. How is early and often a contradiction to agile? Or how does early and often, you know, complement waterfall?

Gerard Cohen

Yeah, that's interesting. So for me, waterfall or early and often in waterfall again means starting at the very beginning, right? So the very definition of the product is, is, is research with the people with disabilities in mind. A lot of times I think, you know, I'll say this, that it's possible that maybe at the essence of agile it might work, I've just never been at a place that actually does agile.

I'm sorry, I've never been... And I haven't heard of any engineers that have worked at a place that that does agile right. It's always some combination or some like like hybrid thing, but there’s just the mere idea of doing things in small chunks, putting it out there and seeing what happens and getting feedback. Maybe it works. A lot of times I just haven't seen it happen.

There's a lot of thought process that has to go in so that the entire picture is considered all at once or else you run into the kind of thing that Joe just mentioned, you know, where it's hard to reverse. Right? And and, you know, as you start to unpack all the different issues, you realize that, oh, this is ultimately this was it is a design decision that that's not accessible.

And there's nothing that we can do on the engineering side to make it accessible. It's just it's just a complex design. Or it may be just architecture decisions that maybe you considered upfront, you know, that you that that are impacting your ability to be accessible. And it's very expensive to go back in time to change, you know, entire architecture decisions and plans because you were in the process of doing things in smaller chunks and not considering the larger picture.

So I think for me that's why I say that waterfall is is is easier to be accessible than agile.

Mike Paciello

And I'm sure you're thinking as well, and Joe, correct me if I'm wrong. When we get the architecture and the design done upfront, correctly, and again, we're thinking about this from the strictly from the perspective of, of accessibility and usability, because I never break the two. The two of them have to be together. If the two aren’t together, then one of them is not going to work well for, you know, for an interaction environment, for a person with a disability.

But, but, you know, I think what you guys are saying is, look, if we can get the architectural design and the user design right upfront and that becomes a constant, then waterfall works more consistently across the board. Is that right?

Gerard Cohen

That's been my experience for sure.

Mike Paciello

Yeah. Yeah, go ahead, Joe.

Joe Dolson

That's a difficult one for me to really voice an opinion on because I have literally never worked in an environment that used any specific engineering system. One of the interesting things about working at WordPress, and I think that's is probably true of a lot of FOSS projects (Free Open Source Software projects) is it's very self-directed. You know, everybody is kind of a bit on on the loose to work on the projects that inspire them or interest them.

And so it's very hard to be systematic. And this can yield a lot of challenges in organization. I mean, the project organization for WordPress is hard. It's hard to keep track of everything that's going on because there are many, many projects that are being worked on that may or may not ever actually be completed. They... it all depends on whether somebody who has the power to actually commit it decides I'm going to be on top of this and make it and push it hard and get it there.

And there are a fair number of people with access to Commit Core to WordPress. But, you know, there's so many things to be done. There's so many, you know, little bug fixes that need to be done here and tweaked there, that taking the time to lead a major change is hugely challenging, especially since a lot of a lot of people involved are just volunteers.

I'm fortunate at this point that I am actually being sponsored part time to contribute to WordPress, so GoDaddy is paying me on a monthly basis to contribute.

Mike Paciello

Interesting.

Joe Dolson

So that makes makes it a little easier for me to put some time, but it's still not full time. I still have my own work to do.

Mike Paciello

Yeah, Yeah, it does. It does raise a level of concern on my part. and just maybe the both of you can can help me through a couple of things. So how you know, how do you validate or verify that the mix that are made, you know, are covering the full gamut of what needs to be done to ensure successful user application.

Right? And the interface. How do you set yourself up with your own checkpoints that you go through? How do you make sure those things don't fall through the cracks? Gerard, what do you say in your line?

Gerard Cohen

Yeah, it's there's definitely a process there that I personally have come up with over time. So there is a checklist that's going on in my head, but it's not... that checklist doesn't necessarily include things that only I do. It also includes other people. Right? Within that process. Which I think is very important because we're talking about humans and human experience, right?

Mine is just a very small piece of that. So there's certain things that I know I can just always count on, right? Making sure, you know, codes validated, semantics are in place, those kinds of things. But I like to make sure and check with my content person. Hey, does does the IA of this make sense? Right? Does the... do these instructions make sense?

Are they easy to understand? Or are they you know, are we are we talking in some weird language that nobody really understands? You know, working with designers to make sure like, hey, not just color contrast, but also like, you know, what are the impacts to cognitive disabilities that that we may be introducing here because this, this, this design or this interaction is mostly geared towards, you know, sighted users with the mouse.

So there's there's there's a lot of things that I have to go through that that I've just kind of cultivated over the years that that helps me keep in line in ensuring that these things aren’t missed. But the most important thing is involving people other than myself. I can't figure it... I can't do it all all the time, all by myself.

It's just not possible.

Mike Paciello

Yeah, and as a manager, you've got a team, right? You've got folks that you're working with. So how do you keep them in the loop? How do you make sure that that knowledge transfer is taking place so they're not missing, you know, some of the some of these key, key aspects of the development for accessibility?

Gerard Cohen

Yeah. Just documenting the process and making sure that it's easily repeatable. And clear communication. And that communication has to happen in various forms. But just, you know, making sure everything is documented for them to always refer back to.

Mike Paciello

Joe.

And again, I would imagine that this is equally as challenging for you because again, if you're dealing with a lot of client client work and you're getting, you know, infusion of designs, development, architecture for a number of different people, different sources, organized or not, how do you make sure that the things aren't missed?

Joe Dolson

Yes, that is really challenging. I mean, this is a place where, you know, depending on where we're talking, there's a lot of rechecking. I mean, usually if we're talking about a consulting project I'm doing, I build in to that process a verification phase. So, you know, it's not just I send them reports of issues and then they fix them.

It's I send them reports of issues, they fix them, and then I verify that they fixed them appropriately. As I have absolutely had cases where, you know, there's a verification and I see what they did and I can see what they were thinking. But they created a whole new problem. Because it's not it's not simple. It's not like it's just a validation of, yes, you did the thing I told you to do.

It's did you do that thing and not create a new problem in the process? So this is kind of an ongoing, constant cycle. I mean, this is particularly the case when I'm working on projects that have development teams who don't have a lot of experience with accessibility. And this is common. I mean, most of the companies I'm doing work with, their accessibility, sorry, their development teams have very little grounding in accessibility.

Also, frequently, a lot of legacy projects, you know, things that what we're actually doing is trying to really skin something that was built 15 years ago. And even if it was built to the best standards of accessibility in 2008, that leaves a lot of room for changes.

Mike Paciello

Yeah, Yeah, no doubt about it. Do you find do you find that your teams are able to work on multiple development projects where accessibility is involved? Or or do you find that you've got to keep them focused? And so you're you just keep their focus, make sure they get this one done right and then move them on to a second to a second project? What do you say Gerard?

Gerard Cohen

Yeah. It depends on the size of the team. Ideally, it's divide and conquer. There may be some some engineers that are dedicated strictly to writing tests and making sure tests are passing. And this is assuming you have a large team, right? There's other teams that are working just on bug fixes. And then there's other people that are going to be working on new features.

Ideally, that's that's the best way that I've had my teams working. So it depends on the size of the team. But I think, you know, if you have more than one person, it's just so much easier to divide and conquer than it is. You know, you have each person focus on a particular thing, but everyone has their own their own gifts and talents that they bring to the table.

And you lead you lead to those strengths. And you, you know, you help encourage that. So I think, yeah, it's it's important to have people, at least for me, in my experience on my teams, having people working on things simultaneously is important.

Mike Paciello

Excellent.

Joe Dolson

I would follow up to that, that it's actually really plays in very closely with this idea of you can't depend on a single user's experience. And having one person do the feature development and somebody else do the testing and somebody else do bug fixes, just gives you three times as many experiences to apply to this particular interface. Whereas if one person takes that all the way through, if they're just missing something, they're going to miss it every time.

Mike Paciello

Yeah, yeah. That makes sense.

Joe Dolson

We all have blind spots.

Mike Paciello

Yeah.

Joe Dolson

I'd like to rephrase that. We all have things that we miss.

Mike Paciello

Right? Right, exactly. So, yeah, so that's good. I mean, I mean, that's where the collective resources kind of what would Gerard was also alluding to, when you know, you've everybody has different talents, right? And they have different aspects of what they what they're really good at. And so they complement. You learn to gather your team, learn what your team can and can't do, and then let them complement one another so there's less likely to be gaps. Less likely to to miss things as as you were, you were referring to, Joe.

So I appreciate that. Well that kind of brings us more to a little bit more on the developer side in terms of coding for accessibility. So most coders have their own techniques. They have their, their own methodologies for how and their own processes for how they how they go about developing an app or website or whatever it is that they're developing.

What what do you what do you preach or what do you, what do you train or what do you like to to promote in terms of best practices at that level? In terms of strictly coding for accessibility? Joe?

Joe Dolson

So I'm a strong proponent of consistency. You know, I know that in accessibility there are frequently a lot of debates on, you know, what is the best way of handling a particular case. What is... What... Sometimes things are not crystal clear and there isn't just one way that is absolutely the best. But in any given project, I think consistency is always best.

You know, if you're using a particular modal in a particular way, you should do it that way every time. Because the user experience is going to be flavored by repeatable actions. And even if they don't, if the user doesn't find this to be their preferred way of doing something, I think they will benefit from it being the same all the way through.

So in terms of the actual development methodology, in what order that somebody does something and how they approach writing the code, I don't particularly care. I think the formatting of the code is very important, but that's not really an accessibility issue beyond the fact that tabs are more efficient.

Mike Paciello

Yeah, Excellent. Excellent. Gerard?

Gerard Cohen

Yeah, this standardization I think is a is an interesting topic. So first I'd say I don't think necessarily coding techniques need to be standardized, but the output, you know, what's actually rendered and experienced by users is what does need to be standard. And like Joe said, within a particular product. At the same time, you know, it's not really necessary to reinvent every pattern every time.

You know, there's some really smart people in the world that have done a lot and learned a lot over the years that we can help build on top of. So it's okay to, you know, crowdsource knowledge for that. But standardization, like I said, is interesting topic. Ultimately, yes, it would be good. But that actually would require browsers and assistive technologies to join in on the standardization as well.

Right? That being said, yeah. That being said, I think there is something I think I think we need to start thinking about the cognitive overload that we're placing on users with, you know, if you, if you're, if you work... In your day job, you use three or four different applications and each one of them has different like dig picker usage for, you know, foreign validation.

The way all those things work. I think that that places a lot of strain on users. And something that we need to consider. But ultimately it's the difficulty is that there's so much variability between these applications and use cases that there's going to be you know, there's definitely going to be some differences there. But I think we need to start thinking about, you know, the cognitive overload there.

Joe Dolson

And that is definitely...

Mike Paciello

Good.

I'm sorry, Joe, but I think that is a great point, an excellent point, Gerard. Go ahead Joe.

Joe Dolson

And that is definitely one of the reasons that I tend to really encourage developers to use browser native features as much as they can. You know, if that feature isn't accessible, then it's not really a great option. But as long as it is, then that means that there's a standard, a default interface that the user gets to experience within their preferred browser environment.

I think frequently designers and developers get trapped in this idea that we need each browser to interact the same as each other browser, where really a given user is most likely using one browser most of the time, and what they need is their experience to be consistent within their browser, not to go to this site and like for whatever reason on this site, this interface behaves like it does on Firefox, but on this one it's on Chrome because the developer has decided they needed to make things consistent.

Mike Paciello

Yeah that's, boy, that's again, that's another, another great point. I just find that to to both of your points, the more layers that we add to, you know, to the base, you know. We used to only talk about operating systems, right? And then, then we get another layer of Internet and then web and then applications on top of that browsers, All of those layers add another level of complexity, and I'm using an assistive technology to interact with them that may or may not be interoperable, usable with, you know, whatever the browser, the interface is or the rendering interface is.

So to your point, Gerard, over the last ten years, maybe you even just use the five years because you just throw in the notion of social networking, all that's added to it, right? Suddenly the user experience has become very, very complex. It's really hard to design a system if you're not focused on it directly, you know, being goal oriented, to make it, you know, three interactions and that's all I need in order to accomplish a task at any given point. It's just and that's the old usability mantra, right? A user should not have to interact, you know, no more than the three clicks. And I find it almost impossible to get to that point. So those are those are great points that you both brought up.

I'm going to touch on another a little not controversial, but somewhat touchy topic. Automated versus manual testing.

Gerard Cohen

I'm here for it.

Joe Dolson

[laughter]

Mike Paciello

Cool. All right. Good. So you get to speak first. How do you feel? How do you do it? How how does your team perform their testing, Gerard?

Gerard Cohen

Yeah. So I think I'll start off by saying that between automatic or automated and manual testing, it's both. It's always going to be both. And it's not necessarily the type of testing that's the best. It's really the timing of when these tests, these types of tests are done. So, for example, linking a dev time, you know, with an ID is super important, right? Using a browser plug in.

Right? So most engineers every once, you know, a couple of times a day, they're going to pop something up in their browser to make sure that everything's functioning properly. Perfect time to hit that button and get it tested by some some accessibility testing browser plug in. Right? And then at that point, you know, once you have enough of the experience done, it's good to get an accessibility tester to do some light light manual testing.

Right? Just to make sure you're you're going down the right path as far as the entire experience is. Then you have unit tests running and CI, right, to make sure that you're not breaking anything. And then at that point, then you have a full manual accessibility testing to validate the entire experience. And I always actually, I always recommend. QA to run the same automated test as that the engineers are using.

And if there's any failures, then it automatically gets kicked back to the engineer. Like they don't do any manual testing until those those tests are cleared because we really don't want, I don't want manual testers wasting time, you know, finding things like form elements without labels. These are things that that have been automated away for years already. And the important thing is that a lot of these basic accessibility issues that these testing tools finds, they actually mask deeper issues from manual testers, right?

So clearing all that stuff ahead of time with the automated tools, you know, great will greatly reduce the Dev QA cycle. And you know, to me personally, if a accessibility tester right like if QA the final stages of QA, if they fail you know anything based on automated tests more than a few times, for me that becomes a performance issue for the engineer that needs to be addressed because now it's a now it's an issue of code quality.

It's not just being inaccessible. This is just basic code quality. So that that's... The last part actually is then a return back to automated tested with established. Once you've established that everything is good and as accessible as possible, I like to implement end to end testing just to prevent regressions. So yes, a combination of of automated and manual is required.

Mike Paciello

Excellent. Yeah. Thank you. Thanks. Joe?

Joe Dolson

I mean pretty much 100%. I would mimic exactly what Gerard was saying. For me, I kind of divide the testing needs into three different categories. There's immediacy, consistency and thoroughness. And immediacy is kind of the, you know, the IDE linting and browser tools where you can just do something immediately, test it, and say, oh, I forgot that. And that's really valuable for saving engineering time because you can get things right away.

There's no there's no time lost in getting that. Then consistency, that's kind of those, you know, end to end tests, all of the automated things to make sure we're always catching these things and just making sure we don't lose track of that. And then thoroughness is where we really need those manual tests by qualified QA people that can be thorough, make sure we've covered all of those things and throw back to us things that we've missed.

Then. Then we can find out can this be incorporated into any other testing that we that we have? And so it's the same basic concept. I just I kind of divide things into these different categories of tests and, you know, some of them can be automated and some of them have to be manual, but you can't really get away with throwing one of those out.

You need them both. They serve different purposes.

Mike Paciello

You know, there's no doubt about it. Now, both of you, I think, Gerard, you use the term accessibility tester and and Joe, you talked about individuals of that with the with a similar skill set. Do you find that there are are more opportunities for individuals with disabilities themselves to be these accessibility testers as opposed to say, you know, quote unquote SMEs or or individuals who have been doing some, you know... Non-disabled individuals who've been involved in doing some of the testing themselves using a screen reader, screen magnifier, whatever it whatever tool that they're using, Do you find there more opportunities for people with disabilities themselves to become the testers in complementing the development teams or your development teams? Joe I'll ask you first, please.

Joe Dolson

Yeah. So both things have their place and it depends a lot on kind of, you know, budget and scope matters. You know, do you have enough funds to hire one person to do everything? Do you have the bandwidth to get a lot of different people? Because in order to really get good coverage with people with disabilities, you need a lot of people representing a lot of different sets of capabilities.

What I find is the best thing to get out of people with disabilities who are using assistive technology is really usability testing. Because that's kind of where you can, you know, a subject matter expert can look at something and be, this doesn't work, this does work. But it's not the same as getting the quality of experience testing you can get with somebody who actually is depending on this assistive technology and can just tell you, well, I can do it.

But boy, that was unpleasant. And so that that is a critical thing that I don't think that there's another way you can get and that you absolutely have to have people with disabilities doing your testing to get a good experience with.

Mike Paciello

In in that area. I kind of prefer control task testing because the other part of this that we haven't really talked about as much today, but I know you guys are concerned about is workflow. And oftentimes workflow is as much from from a... especially from a visual standpoint, the workflow and the structure of that has to be different in order to better accommodate users with disabilities.

So, you know, so that's something, that's why I like using control task testing, because then I can walk them through, here's how it was intended to work. This is a process that you were supposed to go through, but you're a user with the screen reader and it doesn't quite work that way. So, you know, I could pick up on those things in the user testing at that at that level.

Gerard. How about your thoughts on users who are themselves individuals with disabilities involved in the testing process?

Gerard Cohen

Yeah, lived, lived experiences will always trump, you know, any kind of knowledge that I may have. So there's definitely more opportunities that, there's not enough opportunities right now for people with disabilities to be. I think I think that's a perfect use case. But it does. It does ultimately, when you're again, when we're talking about the human experience and how that changes and the intersectionality of different disabilities, it's important to, you know, have a nice cross section of of people testing things.

But ultimately people with lived experience is super, super important. One thing, though, is a of times I've noticed that non-disabled people will assume that a disabled person is an expert on disabilities. When really all they are is an expert in their in their lived experience. That doesn't mean that they can't be an SME themselves, but that that's, I think, a really big assumption that we need to stop making about, you know, people with disabilities.

Mike Paciello

Yeah so that's a great that's a great point because, you know, another thing that is really come to the to, to the fore of of late because of individuals like David Sloan and Whitney Quisenberry, and some of the usability folks is the development of personas. And personas help you to kind of match up with the with you know what you're developing for for your your customer.

Right? So who's using my my app? Who's using my website? What kind of people are they? What what is their lived experience? So at that level, when we're doing that kind of testing, the same kind of mindset, both from a usability and a developer standpoint has to be applied where it involves people with disabilities. So that's a that's a great, great point, Gerard.

I really appreciate that. We're getting down to the back end of of of our discussion here. But let me ask you this question. Do you do you find that budgeting both in terms of human capital, in monetary, but, you know, budgeting becomes a challenge? And how do you make that work within within your within your environments and in your development space?

So, Gerard, I want to ask you, because you're going to speak to it, I think from, you know, much more from an organizational standpoint than Joe from a subcontractor. Gerard, what do you how do you respond to that?

Gerard Cohen

I'm sorry. I'm going to I'm going to need you to rephrase the question.

Mike Paciello

Okay. How do you fit budgeting into your development plans? And when I say budget, I'm not just talking about, you know, the financial aspect, the monetary aspect. I'm also talking about human capital.

Gerard Cohen

Oh, yeah, this is this is an interesting concept because a lot of times, you know, teams that are dedicated to accessibility are always underfunded and understaffed. You know? And a lot of times the optics of it to me is very unfair. So for example, you’ll have like a typical agile team is supposed to be 7 to 8 people, but a, you know, an engineering team for accessibility may be two people, you know?

So that's that's you know, I would start with that right there. Let's just make sure that everything's equal across the board. So that's that's super important. But when that's not the case, I think it's it's important that you start to operationalize everyone that's involved. So not about just budgeting for accessibility people. It's how can I budget to make sure that all everyone else is doing what they needed to be accessible?

So are they taking the time to do the training? Are they taking the time to do the testing? So I think the budgeting aspect is a lot bigger than just a particular accessibility team.

Mike Paciello

Excellent, Excellent. Thank you for that, Gerard. Joe?

Joe Dolson

Yeah, so this definitely speaks to the two different sides of what I'm working on. You know, within my own personal business, I'm obviously working on small projects with small budgets. And so for me it's a it's kind of a calculus of what is the most effective thing I can provide for this client within their limited resources. So, you know, it's it's very heavy on just prioritization.

You know, I, I know realistically when somebody comes to me and is like I have $4,000, what can you do for me? I can look at their stuff and like, I can definitely not do everything. And so we're going to we need to prioritize what are the elements of, say, in this case we're going to talk about websites.

What are the elements of your website that are the biggest blockers? What are the things that are most global and what are the most important workflows? And that's where I'm going to budget my time because I know that we have to we have to draw line. Small. I... so my mother was the executive director of a nonprofit that focused on people with disabilities.

And so I'm very intimately familiar with the challenges of funding small nonprofits, and I don't want them to be struggling with barriers because they don't have the funding. So it's always going to be this this really complicated decision making of where can we... where do we have to draw that line? Because they also need to fulfill their mission as best as they can.

Otherwise they can't get funding if they can't fulfill their mission. So I do tend to tell them if you have something that isn't perfectly accessible, you're still providing a better service by making it available to some people than by making it available to nobody.

Mike Paciello

Right? Yeah.

Joe Dolson

And that's a hard decision to come to sometimes because my instinct is always, no, this has to be accessible to everybody. But that that isn't the case for a small nonprofit. It has to be available to somebody.

Gerard Cohen

That's hard.

Joe Dolson

In the WordPress world, it's a lot more like what Gerard is talking about. I mean, you know, WordPress does have an accessibility team. It's almost all volunteers. Most people are volunteering just a few hours a week and almost nobody is funded to actually contribute specifically to accessibility. So we are heavily dependent on relationships with people who are funded, who are primarily contributing to other areas. Which is in some ways fine because practically speaking, accessibility draws on all of the different pieces and parts of the WordPress environment, but it also makes things challenging. You you end up kind of in the role of an engineering manager, but trying to do it in 6 hours a week.

Mike Paciello

Yeah.

Joe Dolson

Across 600 contributors who you can barely even track everything. So it is a very difficult environment and it is it all comes down to underfunding of accessibility.

Mike Paciello

Yeah, across the board. That's really where we are. Gerard, it sounded like you wanted to add to something Joe Joe said.

Gerard Cohen

No, I was just, I was just agreeing that's a very hard space to be in because there's, there's always constraints with time and budget that that conflict with your inner desire to help and support as many people as possible. So I definitely empathize with that that difficulty that you have there.

Mike Paciello

Well, listen, guys, just as I wrap things up here, let me just get your last words in. So what is the message? I know there's I know there's no real answers to this, but I'm going to go for it. What is the number one recommendation you would make to developers where accessibility is concerned? So, Joe, I’m gonna start with you.

Joe Dolson

Number one recommendation is probably learn to test with the keyboard because it gets such a high volume of issues dealt with. It's not necessarily it's not the hardest issues to hit and it's not the necessarily the most blocking issues. But in terms of just getting a large number of things dealt with that are hard to test with automation, you can you can make so much progress with, you know, 5 minutes on the keyboard.

So that's kind of my number one.

Mike Paciello

Huh. That I would not have expected that I yeah, I get it. I totally get it, but I would not have expected that. Gerard, how about you?

Gerard Cohen

Yeah, on top of keyboard, I would say for me that semantics are extremely important and and that that's independent of the technology that you use to render semantics. I'm not going to get into you know React versus any other you know libraries or technologies there. But ultimately what's rendered in the browser semantics is super important. So making sure you know that everything every all interactive elements have a proper role, have a proper name and, you know, the state is accurately communicated, will get you a long way.

And as far as testing additionally to keyboard, there's a lot that you can do in the browser, like in the accessibility inspector with all the browsers. That will give you a lot of really good information and make sure you're doing the right thing before you even have to fire up a screen reader. So you take advantage of those tools.

Mike Paciello

Excellent. Excellent. Joe Dolson. Gerard Cohen. Guys, thank you so much for joining us today on Accessibility.com. This was as I mentioned earlier, this is the second part of our three part series that we're preparing for Global Accessibility Awareness Day. And I really appreciate what you guys brought to the table today to help us understand what needs to be done, what what kind of approaches that we could take towards developing for accessibility.

So thank you both.

Gerard Cohen

Thanks, Mike.

Joe Dolson

Thank you so much. Mike.

Gerard Cohen

Thanks, Joe.

Joe Dolson

Thanks, Gerard.

CLOSING

Lori Litz

Thank you, Joe, Gerard, and Mike for that excellent discussion on developing for accessibility. Again, the event was recorded. It will be available this evening. I will go ahead and email out instructions in a couple of hours once I have that all set and ready to go to give you the details on how to access the presentation and the transcript and any other supporting materials that the panelists provided or we felt you might find useful.

Accessibility.com does publish a blog. If you want to go ahead and check that out at Accessibility.com slash blog. Forward slash blog. In there we have a team of writers that put together some wonderful content to kind of further dive into some of these different areas. We also publish a monthly digital accessibility lawsuit. So if you want to take a look at any of the previous months lawsuits, you can access that on our website as well.

We will be back tomorrow with a Deploy for Accessibility, again with our host, Mike Paciello, and Becky Gibson and Leonie Watson. So that's a great event. If you haven't registered for it yet, you can do that to make sure you don't miss it. And if you can't attend it live, we are recording that one as well, so you'll be able to view it on demand.

If you have any questions, please don't hesitate to reach out to me at Lori L-O-R-I at accessibility dot com and I will be happy to answer any questions that I can or get them to somebody that can answer them. I hope you all have a wonderful rest of your day and looking forward to having you join us tomorrow.