Wrapping Up

[00:00:00]
>> I want to send you off into the world with some resources, some encouragement. I may add to this list over time, so if there's anything I missed, I think there were a couple of tools and techniques that I'll go and incorporate. There are some notable design systems and component libraries, React has quite a few, I think just, there's been a big demand for it.

[00:00:20]
React ARIA from Adobe, we saw their focus scope, that was a pretty handy component, but there are whole other sets of components that they've made- Shocker UI, which is for React, and Vue and maybe more. There's Coreui for Vue, another library called Radix, and I haven't tested every single one of these, I will caution you.

[00:00:44]
And even if something does say it's accessible also, just kind of a last plug is that don't take their word for it, [LAUGH] we've to test it. I mean, we're all human, right? So we might build something, and it worked when we published it, and then life happens and stuff maybe doesn't work as well as we thought.

[00:01:03]
So, as authors of libraries, and or as consumers of libraries, we we trust but verify. Try it out, try out a demo site, use those debugging techniques, and at least see what's the state of it, and how is their GitHub library or GitHub repo, do they respond to issues?

[00:01:26]
Are they kind about it, or are they maybe not so nice about it? You might be able to do kind of a gut check of before we convert our whole app to this design system, what's the experience gonna be like trying to fix things? Question?
>> Have you looked into Google's material UI?

[00:01:46]
>> Yes, not recently, I'd have to look again, but that could be one to check out. I did work on Angular material a while back, and yeah, there's some legacy there, maybe a reason why I didn't include some of that stuff. But I know a lot of accessibility does go into some of these libraries, so that one could be worth a look for sure.

[00:02:12]
So some last training and resources to send you on your way, there's probably more accessibility stuff here than you ever bargained for. The third Thursday in May, every single year is Global Accessibility Awareness Day, and there are talks and events and all kinds of things, it's great. I think every day should be accessibility awareness day personally, but that's a big one for the community.

[00:02:37]
If you're anywhere near Toronto, Accessibility Toronto is amazing, I don't know how they do it, honestly, they do meetups and a conference, they do a gaming accessibility thing that's really neat. Also in Toronto is a company called Fable, they are a user testing group that you can hire to test your products.

[00:02:59]
They have disabled testers you can work with to test prototypes, pages, and they can help you highlight issues if maybe you don't have people in house to help you with that. And then I have a series of guidelines for accessibility, some more courses, and a list of people to follow if you're so inclined.

[00:03:21]
And I guess some parting wisdom or love to send with you is just that accessibility can be a way to stand out from the crowd. Like I know a lot of people are looking for jobs right now, and if you have, as a hiring manager, you have two candidates who are really solid and one developer has more accessibility expertise, that could be pivotal for teams.

[00:03:46]
It's not gonna be like the only thing, but it could help. So some employers do prefer accessibility certifications once you start to get into accessibility specialist roles, but I don't I think you should need that for a more general role. But find your strengths, find what you're into and, yeah, I just went through a job search myself, so I wanna send you some kudos, keep going.

[00:04:13]
Another question?
>> Do you ever use services like Stark to maintain a history of accessibility reports over time versus doing manual checks every month one?
>> Good question, yes, Stark is amazing, it has tools for figma and other things. I haven't used it for that, but yeah, kinda thinking about working with teams, and we'll get into some of this in the enterprise accessibility workshop, but yeah, very manual tests are not that repeatable, especially across if you have multiple team members.

[00:04:50]
So, finding tools where you can share results, have a repeatable process that will become more important as you do more of it, yeah, I think there's very varied maturity in how you approach that. I think some teams are just real scrappy and kind of figure it out, some teams are bigger enterprises and they need more elegant solutions to those kinds of problems.

[00:05:15]
So, I think a lot of the tools like Axe, they have whole product suites around that type of thing, so I think if you're getting into team management of accessibility, you might consider looking at one of those more enterprise type tools.
>> How about in your continuous integration build pipeline or whatever, do you see testing incorporated there at all?

[00:05:42]
>> Yes, definitely, and that we will get into an enterprise accessibility as well, but with continuous integration, there's some great opportunities to highlight it. I see if you have test coverage for accessibility, and your teammate publishes a pull request and it fails the tests, guess who has to go fix the test before they can ship their PR?

[00:06:07]
So I think it really can be helpful for catching stuff before it ships, for things like Axe, if you were running Axe in your CI pipeline, it's kinda debatable whether you wanna have those results fail or not, it kinda depends what they are. You might have some pre-existing accessibility failures that you either have to ignore or you're just always gonna fail builds, I'm not really sure.

[00:06:34]
So, I think your feature tests that you write for your stuff that you know are reliably tied to stuff that you actually can control, those tests should fail builds, like keyboard tests and stuff. But yeah, maybe not a full accessibility test API and continuous integration, I think maybe that's more of in your development, but different teams might have different approaches.

[00:07:05]
>> All right, thanks, Marcy.
>> [APPLAUSE]