Working with Teams

[00:00:00]
>> Okay, so working with teams. It's one thing if you're working by yourself on a project, your commit messages and things don't have to be [LAUGH] that useful for teams. And you can make all the decisions you want. But when you're working with other people, there's some things you might wanna be aware of with team concerns and processes.

[00:00:18]
So I have some ideas around how to make this a team sport. Because that's how we're gonna make the biggest impact is if as many of us are chipping in as possible. So sort of the reality of some of the accessibility efforts that we put in are that we have to have accountability.

[00:00:35]
We have to actually make it a requirement and make it part of the definition of done. And so you have to kind of get your leadership team on board if you can, so that you have time to actually spend on it. I mean, this is gonna be a negotiation in some cases where it might have to get worked on after a breaking change ships.

[00:01:00]
You might need to decouple fixes. I had this come up the other day where I really wanted to rip out a component that was super inaccessible. But there was a display bug that I was trying to get the time, the cycles to work on it. I was having issues and so I'm gonna have to decouple things, fix the display issue and then come back in and the next sprint and do the accessibility work.

[00:01:25]
So sometimes you don't get to just rip it all out and do it. You have to negotiate how to make it part of a definition of done that people agree with. Yeah, it's part of the reality of doing this stuff sometimes. And so part of this also is, who takes responsibility if something is inaccessible gets shipped?

[00:01:48]
We heard a story earlier about a lawsuit. Those are super common, and so sometimes those happen after things have shipped that it's not a surprise at all because you knew it was inaccessible. And you tried to do something about it, it's like, well, who's held accountable for it?

[00:02:07]
It really should be the decision makers that said, no, we are gonna ship it. I hear you, we're not gonna tackle it this cycle. That person has to be held accountable. So these things all come up, it's not always pretty, but we wanna document things as much as possible.

[00:02:25]
Document your findings, find what you tested at that time, if you have to put it down, but you've done some of the preliminary work, keep your code in a branch, have some documentation of what was the state of it. So that if you do have to come back to it, at least you're not totally starting over.

[00:02:44]
That can be helpful. When you're doing code reviews, this is a really great time to try and get accessibility addressed in the moment, cuz we don't wanna add to our debt. I just accrued some accessibility debt at my own job this week, it happens. But when you're reviewing people's code, that might be the time for people to make some changes, and hopefully, you can get stuff in at that time and not have to come back to it.

[00:03:11]
There's sort of an art to how you provide this feedback, cuz we want people to want to work with us even though we're the bearers of bad news sometimes. We don't wanna make people feel bad cuz we want them to fix their stuff, so we have to be tactful.

[00:03:28]
[LAUGH] But surface it at the right time like, hey, we need to make this click event and put it on a real button so that a keyboard user can operate it. That's one I see all the time, where there's click events on divs. And if they can't fix it right then, then open up an issue that will get put on the backlog and make some good trouble over it.

[00:03:55]
We don't wanna be like, we're gonna be squeaky wheel about it in the way that you can in your own work context, but we wanna make sure that things don't just languish in the backlog and never get done. So you have to kind of find that right balance of, is this the right time to do it?

[00:04:11]
I understand the team's under a lot of pressure, how are we actually gonna make sure that this gets fixed so it doesn't just get shipped inaccessibly and go out like that way forever? Code reviews, and then use consistent tooling and processes. If you're all using the AX extension, pay attention to what version it's on.

[00:04:35]
Make sure you're all updated, or in your issues, if you've have AX results or something, maybe document what version the API was on. That can be helpful to know so that if something changes, you have a track record of how you tested it, even just how you tested it.

[00:04:55]
Tab into the page with a keyboard, turn on the AX extension, whatever stuff steps you took to reproduce that issue, put it in your issues, in your pull requests. I find people are very light on documentation [LAUGH] in PRs, or pull requests, or issues. So just sharing what steps to take to reproduce an issue in general can be super useful.

[00:05:22]
And as you get into accessibility maturity, companies that are much more serious about it and have to have more attention on it, there are tons of tools by all of the major accessibility companies that you can sort of upscale into some of those pages tools if you need to.

[00:05:42]
Question?
>> How much are we asked to estimate when factoring in accessibility? What percentage of additional time should we consider adding?
>> Good question. The figure that I heard working with a very large tech company was around 30%. And I think they were being kind of generous about it just because they're a big company.

[00:06:06]
It's a slow moving ship, there's always delays and cost overruns in general. So I think they were trying to be, I don't know, sort of forgiving about it. But that could be on the high end like 30% of your time throughout the whole whole process. I mean, it does cost money to do it, to cost time and money.

[00:06:26]
I think as developers, there are some easy wins that we can do that should just be part of our regular flow. And 30% of our time, that seems a little bit high if you're doing it all the time, just as a matter, of course. But it's kind of hard to quantify.

[00:06:42]
I will say that the cost of not doing it would be way more. If you have to rebuild your whole site, how much is that gonna cost, or the legal risk, or the lost revenue? So some of that padded estimates up front could be you're trading that time for not having to redo everything later, or missing out on a huge contract because your competitor is accessible and you aren't.

[00:07:08]
So kind of put it that way. Would you rather plan it a little bit up front and have it go more smoothly, or just go cowboy style and we're just gonna take a chance and not do anything? Unfortunately, I think that's what a lot of companies do. But I think there's some easy wins that we can work in even if our broader organizations aren't quite up to speed yet.

[00:07:33]
I mean, I'm the sort of just do it and ask for forgiveness and not permission type of person. But this does take time, work is work, it does take time and effort, so we have to find that balance that works best for us, yes.
>> On the team, I built something that disabled the cursor on localhost on Wednesdays and it frustrated a lot of people, but we found and fixed a ton of bugs.

[00:07:58]
>> Nice, round of applause for that, that's amazing. [LAUGH] l actually have a tool that I wrote that's kind of similar called No Mouse Days. We might have it in the slide somewhere. But there is a tool it basically is that same idea of having a package that would automatically hide your cursor.

[00:08:24]
This will hide it in CSS in any site that this package is included in, if you configure it that way, but yeah, it's frustrating. But sometimes you have to take desperate measures to really get through, so that's amazing, good job. [LAUGH] Okay, so going beyond compliance, accessibility compliance, and I have a meme from Austin Powers of Dr. Evil Goin, our site is accessibility compliant.

[00:08:54]
And I can't tell you how often I see this as a line item and a doc of, we aim to meet WCAG 2.2 AA, and then there's literally no process to actually do it. Click events on divs that ship and I'm the only one in a PR review going, can we change that?

[00:09:15]
You might be the only one even though it's literally in your documentation. So saying something is compliant and actually making it accessible are two totally different things. And you can say it's compliant, but it probably isn't, for one. It might have been for a short period of time before you made changes and shipped it again.

[00:09:37]
So if you had a big audit and it was let done months and months ago, it's probably not relevant anymore if you're shipping software regularly cuz things change. And so when it was tested to where it is now, it's probably not the same at all. So we wanna go beyond compliance.

[00:09:56]
We wanna make a good experience and it's something that we want to work on iteratively. We're always like, we're improving any kind of bugs, or any kind of software features, accessibility is just part of that process all the time. That's how it's gonna be the most successful. So I wanna kind of get past compliance, especially when it comes to the web content accessibility guidelines, which are great.

[00:10:20]
But they're just a starting point. It's all about, is the experience good? So a better way to think about this, I mentioned it being a constant work in progress and something that we iterate on. But it also needs to be part of the design. It needs to be part of your product DNA, and the earlier you incorporate that, the better.

[00:10:42]
Mostly cuz depending on how your work gets done, design might have been way earlier and you can't change it now. So if we have issues with contrast or font readability or things that are more visual characteristics. That's stuff that, that ship has sailed long ago, and you can only fix so much as a developer.

[00:11:07]
That's design debt right there, turning into accessibility debt. So we wanna make changes as often and as early as we can. If you can put an accessibility statement on your website, that could be really helpful. It gives people with disabilities a way to contact you if they do have an issue, and it's a really great tool to have to say, hey, these are the standards we're aiming to meet.

[00:11:34]
We're working on it. You don't wanna be like, we nailed it, we're great. Just putting the statement here to say, we're compliant, that's not the goal. The goal is to say, hey, this is what we're trying to do, we're continually working on this, if you find an issue, please tell us.

[00:11:49]
Cuz those feedback comments are gifts, they really are helpful. And so you wanna give people a way to email you or chat with you and tell you. Cuz they might be in a combination of browser and screen reader that wasn't at the top of your list. So maybe they could help you identify a super blocking issue that you just weren't aware of.

[00:12:10]
So accessibility statements are really great for that. And then don't stop at tooling, just like Lighthouse and AX saying, okay, zero issues, 100%, you're good. That may not be the full picture. There's a great article that I linked to my slides called Building the Most Inaccessible Site Possible with a Perfect Lighthouse Score by Manuel Matusovich.

[00:12:35]
And he highlights perfectly this problem that you could have a clean bill of health with an automated tool but it could still be terrible. So there's some links in here to read a little bit later. I would like to dive into actual debugging. Be ready for that.