Talks
How to make your application accessible (and keep it that way!)
Edit
#accessibility-a11y
#user-experience-ux
#inclusive-design
#ruby-on-rails
#team-dynamics
#software-development-practices
#github
Summarized using AI

How to make your application accessible (and keep it that way!)

Joel Hawksley • October 07, 2024 • Boulder, CO

In the talk titled "How to make your application accessible (and keep it that way!)" presented by Joel Hawksley at Rocky Mountain Ruby 2024, he highlights the urgent need for accessibility in technology, noting that over 70% of websites are largely inaccessible to individuals with disabilities. This session aims to share the lessons learned from scaling GitHub's accessibility program and provide actionable strategies for other organizations.

Key Points Discussed:

  • Community Values: Hawksley emphasizes the Ruby community's spirit of inclusivity and caring, contrasting it with the reality of inaccessible technology products.
  • Tools and Measurement: In his previous talk, he discussed using automated accessibility scanners like AX to identify issues, while this talk focuses on scaling accessibility efforts across large organizations.
  • Engaging Leadership: He outlines the importance of convincing leadership to prioritize accessibility, backed by the legal risks associated with non-compliance.
  • Accessibility Goals: Hawksley stresses that accessibility must be integrated as an organizational goal and not just a one-time fix.
  • Ownership and Responsibility: Establishing clear ownership of accessibility responsibilities within teams is vital to ensure ongoing compliance.
  • Lived Experience: Involvement of individuals with disabilities in testing products is crucial to creating an accessible application.
  • Training and Resources: He suggests companies provide extensive training to employees on using accessibility tools and designing inclusive experiences.
  • Investment Requirement: Talks about the need for significant investment, stating GitHub spends between $5 to $10 million annually on accessibility initiatives.

Significant Examples:

  • Legal Risks: Hawksley references a rising trend in digital accessibility lawsuits, emphasizing the need for compliance not just ethically, but also to mitigate legal liability.
  • Process Implementation: He discusses the implementation of a service catalog to assign accountability for accessibility, detailing how it has improved compliance and responsiveness to issues.

Conclusions and Takeaways:

  • Measure Accessibility: Companies need to prioritize measuring their accessibility progress using reliable metrics.
  • Empower Your Team: Organizations should empower individuals with lived experiences to drive accessibility efforts.
  • Cultural Shift: Emphasizing that accessibility should not merely be a compliance issue but a cultural value within tech organizations, ensuring that all individuals, including those with disabilities, can effectively use their products.

How to make your application accessible (and keep it that way!)
Joel Hawksley • October 07, 2024 • Boulder, CO

Our industry is shockingly bad at accessibility: by some estimates, over 70% of websites are effectively unavailable to blind users! Making your app accessible isn’t just the right thing to do, it’s the law. In this talk, we’ll share what it’s taken to scale GitHub’s accessibility program and equip you to do the same at your company.

Rocky Mountain Ruby 2024

00:00:14.920 so one of the things I love the most about our community is how caring and
00:00:20.000 welcoming we are as I'm sure you have all seen in your time here I think that something that really
00:00:27.160 struck me when I think when I was thinking about that is that us programmers are often stereotyped as
00:00:32.520 being you know really out of touch and I'm really proud of how in the Ruby Community we've really come to value and
00:00:39.320 embody that welcoming spirit that inclusivity but I have some bad news as
00:00:46.600 an industry the products we build are incredibly unwelcoming to people with
00:00:53.239 disabilities depending on who you ask between 70 and basically all of the percent of the internet is a effectively
00:01:00.359 Out Of Reach for people who are blind but I have some good news we can do better and I'm here to show you
00:01:07.960 how so we've been working really hard over the past couple of years to make GitHub more usable for people with
00:01:13.439 disabilities and I'd love to share what we've learned so you can do the same at your company I might as well do a quick intro
00:01:20.000 my name is Joel I'm a Staff engineer at GitHub uh I would kind of describe my role as being one half of our UI
00:01:27.360 Architects so we have someone who's a little bit more re focused on I'm the more traditional rails focused person uh
00:01:33.520 I work on all sorts of UI related things as they affect the company such as accessibility and I live
00:01:40.240 like a 10-minute drive from here so Spike thank you for throwing a conference that was super close uh I can
00:01:45.320 tuck my one-year-old boy into bed tonight uh thanks to you and I don't have to you know FaceTime him
00:01:51.200 instead so as a quick recap I actually gave a talk uh last year about accessibility tooling I shared how we
00:01:57.560 use ax which is an automated accessibility scanner to automatically surface accessibility issues in our app we happen to highlight
00:02:04.200 them in red uh if you're a staff member uh but I talked about how can only catch so much it's just automation it's not
00:02:10.160 complete I shed how we use some custom abstractions like in this case a form Builder uh to Def find certain classes
00:02:16.920 of accessibility errors out of existence and then I also showed a lookbook something I was just telling
00:02:22.080 you about uh a couple minutes ago it's a tool like storybook that we use to build our UI pieces and isolation and that
00:02:28.000 that allows us to more thoroughly test them for excess ibility issues and for those of you who are here I think I hope
00:02:33.840 you remember it as being a good talk I think it was well received uh but what really struck me is the questions
00:02:39.040 afterward had nothing to do with the talk um and to me that was a sign that I
00:02:44.400 gave a talk on the wrong topic uh so today's talk is answering those questions in more detail and the
00:02:50.800 questions I got really amounted to uh questions were all used to getting as rails developers which is uh that's nice
00:02:57.319 but how do you scale it uh it's a question I'm definitely used to uh especially at GitHub where I feel
00:03:04.159 like we're constantly being used as an example of how rails does and doesn't scale uh quite
00:03:11.120 honestly but to be more specific there were kind of three questions one was how do you get leadership to
00:03:17.560 care how do you make your entire application accessible these tools are cool but how do you scale it up to like
00:03:23.599 something big and then how do you keep it that way like say we go and invest all this money how do we make sure we don't regress
00:03:31.720 uh but before I get too far uh how many of you here have accessibility goals of any kind at your
00:03:38.120 company okay not bad um how many of you here have worked on them
00:03:45.000 personally about the same hands cool um you know we've long worked to make iub
00:03:50.920 accessible we've had various teams across the years make improvements of what I would call like fits and starts but there was never really a widely
00:03:58.040 coordinated effort you know we never really had any specific goals that we like we want to get to this standard in this time uh that all changed uh when we
00:04:06.040 got bought uh as it turns out Microsoft cares deeply about accessibility not
00:04:11.519 just because it's the right thing but because it's often a non-negotiable requirement of the big government uh and
00:04:17.519 Enterprise sales contracts uh that Microsoft is famous for there are of course many
00:04:23.280 non-technical and non-economic reasons uh to make our products accessible I think that we could all generally agree
00:04:29.080 that it's the right thing to do uh but I don't think I need to convince any of you of that so I'm going to focus on the
00:04:35.680 pragmatic if not capitalistic reasons uh you should do accessibility and why you should uh you know take those reasons to
00:04:41.720 your company so a big one is that accessibility is a legal risk uh well
00:04:47.000 I'm not a lawyer uh most of my work has actually come out of and been funded by our legal department and I wouldn't be
00:04:53.320 you know giving you a talk about accessibility without mentioning that not having an accessible application is
00:04:58.479 a very real legal risk and often a significant one uh many companies have faced legal pressure for accessibility
00:05:04.800 issues and GitHub is one of them part of my work I'm doing is actually in response to Legal pressure we've
00:05:11.680 received and this is not uh this is not anything new I don't know how many of you are familiar with the greater
00:05:17.840 accessibility field but lawsuits have long been what some would argue the only effective Tool uh for making buildings
00:05:24.440 accessible for people with disabilities uh there's a New York Times article uh app the man who filed more than 180
00:05:31.400 disability lawsuits um talking about how you know for decades wheelchair users have had to sue businesses that don't
00:05:37.360 have like a ramp or a table they can use so that they can go DME uh the same is true for digital
00:05:42.560 accessibility uh according to Forbes who does not know the definition of exponential
00:05:49.039 uh there were over twice twice as many uh digital accessibility lawsuits
00:05:55.240 filed in 2023 as in 2018
00:06:00.919 as a former journalist this just it just kills me um but I showed this slide to my
00:06:07.120 colleague earlier this year and she's like yeah that's kind of impressive but did you know that in the last five years
00:06:14.039 80% of the top 500 e-commerce websites in the world have been sued over
00:06:19.360 accessibility it's like most of them so if you're in the 20% this talk is fre
00:06:25.319 you well maybe or maybe you're doing a great job and you didn't get sued because of it
00:06:30.919 so our most most concrete goal for github.com is really pretty simple we want to make it so that when people use
00:06:36.680 our UI uh with assist of Technology they are not blocked they can accomplish any
00:06:42.120 goal that a cited user uh is able to accomplish and in practice that means
00:06:47.479 complying with wiag 2.1 soon to be 2.2 these are the web content accessibility
00:06:52.759 guidelines It's actually an international standard uh and it's used by companies and governments in
00:06:58.160 purchasing decisions in fact if you've seen the new European regulations I think they took the wick Haag numbers
00:07:03.360 and like appended a suffix to them or something like that it's like 211e for like the European version of it um it's
00:07:10.039 it's pretty much equivalent around the globe so whenever I share how we do
00:07:15.440 things a GitHub I think that it's really important to provide some context because we are a very big company and I
00:07:20.759 want you to like take some of the things I'm saying with a grain of salt you know we have about 4,000 employees uh we had
00:07:26.400 like 600 when I joined which is wild um we have about 1,500 engineers and still
00:07:33.080 I will say this every year until it's not true we are still a Ruan rails monolith despite despite what everyone
00:07:40.080 thinks is changing it's not meaningfully changing um almost all of our API traffic and and uh UI traffic comes
00:07:47.560 directly through the monolith uh to this day and that's like 10 billion requests
00:07:52.800 per day something like that probably more at this point maybe uh Nathan Nathan do you uh do you know if it's
00:07:58.960 over 10 yet I have no idea you have no idea okay but does it scale it does it scale yeah exactly right I mean I don't
00:08:06.440 know it's 10 billion scale Are We There Yet I uh we also have around 2,000 Pages
00:08:11.560 which I think is more relevant to the accessibility work like we have 2,000 Pages just in our Monet that we need to make accessible and I think I've
00:08:17.800 inventoried somewhere around a 100,000 additional pages on like static marketing documentation websites Etc so
00:08:24.199 massive footprint uh many of you have been also asking me uh 95% of those routes still are just rendered in Erb
00:08:31.120 made with view component 5% of those routes are rendered with react
00:08:38.719 um no no comment um so what I'm curious here uh
00:08:46.440 how many people here work by themselves how many people here work with at least five
00:08:52.640 people how about 10 uh
00:08:58.240 50 okay I'm I'm very alone here okay how about like a 100
00:09:05.320 500 a thousand okay yeah so it's basically me and the Cisco guys
00:09:12.320 okay uh you know regardless of of the size I think the kind of like the fundamental concepts of what I'm going to talk about today you know do apply
00:09:18.959 across scale but know that there's a lot of process that I'll talk about that maybe maybe you need a smaller version of it than we do um so I think there
00:09:26.600 kind of like three key things we've learned after doing this for a couple CP of years that like actually have impact when it comes to investing in
00:09:32.360 accessibility and the first one is measurement um you got to have a Target
00:09:37.480 right you can't just go out and do it without a Target um second thing is having durable ownership making sure that like everyone can agree whose
00:09:43.120 responsibility it is and then the last one was lived experience like you got to make sure that it actually works for people with disabilities not just that
00:09:49.320 it meets the wick head so a few years uh into my time at
00:09:54.680 GitHub I joined the design organization as an engineer and I reported to basically our head of design for the
00:10:00.079 company and I remember an early conversation with her about how I was really frustrated about how oh there's
00:10:05.320 technical debt everywhere no one uses our design system our UI is super inconsistent and what she said to me is
00:10:13.040 there will always be something wrong like code has never finished like why should we care in this specific context
00:10:18.680 you know how will we know that we've succeeded when it comes to uh UI consistency and honestly just figuring
00:10:24.839 out the scale of the accessibility work we've had to do was a challenge in and of itself before even addressing it and
00:10:31.240 uh one of my favorite I should say favorite a book on this topic is called how to measure anything and it's really really dry um but it basically just
00:10:38.320 talks about how like when you're coming up with a measurement you really need that measurement to be able to accurately boil down to a Boolean value
00:10:46.360 so like basically to tell you whether you met your goal or not and really don't need more Precision than that so
00:10:52.519 you know we're all very well very well aware of this kind of measurement you know tests are like this you know they let us quickly learn if something is
00:10:58.839 good or bad right um so if you think about it like if premature optimization is the root of
00:11:05.560 all evil uh in the case of doing this kind of work maybe making a change
00:11:10.959 without a Target is also a root of evil so we need to come up with a way to measure our accessibility problem and
00:11:18.279 I'll go through how we did that at least for like our like marketing pages so I started with our DNS configuration in
00:11:24.160 our case we have somehow rigged it up through Source control so you make all DNS changes through uh yaml file
00:11:30.399 um and this gave me a list of about the 100 domains that we have public publicly accessible pages on and with that I
00:11:36.839 wrote a script that pulled up in Chrome and ran that X tool I talked about last year and reported the statistics to data
00:11:44.240 dog and what this basely showed is that you know each color in this graph is one of our websites and what this meant is
00:11:51.000 that we had 18 accessibility violations just on the homepage of our roughly like
00:11:56.920 100 properties and this is actually pretty good the industry average is 55 detected by a on a page that's been un
00:12:03.240 remediated um but like these are the things that like are pretty like a is very conservative in what it reports it
00:12:09.120 only reports things that are like very confidently wrong these aren't like warnings these are errors um and I also
00:12:15.320 just say that like if someone comes to your site and can find something that Axe can find it's basically evidence
00:12:21.639 that you didn't even try because like it's like super obvious stuff um and you know these things all
00:12:29.560 these errors all 1800 of them represent potential roadblocks for our customers
00:12:35.320 uh you know if they're using syis of Technologies those are all places where they might struggle to accomplish the goal that say a cited user would want to
00:12:42.399 accomplish so we use the same tooling to scan our design system and you can see like we had a little bit of a of a rocky
00:12:49.480 ride for like our bug bash month but we eventually got it down to zero so this is a way that we trct uh a monthly
00:12:54.880 month-long uh accessibility bug bash we also use it in our system tests so we have I think it's like a dozen
00:13:02.519 critical paths that simulate say like the process of opening a poll request or filing an issue or using GI projects and
00:13:09.320 this is the ax report uh cated for all of those critical paths together over
00:13:15.680 what like a three and a half month time period so this shows our ongoing progress reducing the net the total
00:13:21.399 number of accessibility violations encountered by our customers across critical flows we also track longer term trends
00:13:28.399 for some of our Market critical rules I don't know if you guys use data dog but at least for us it's C at like 15 months so if you want to show something that's
00:13:34.279 like longer than that you need a different tool so in this case we literally just dump stuff into Google Sheets and this is an example of uh our
00:13:42.199 accessibility lint rules so these are the number of violations per rule uh just for a couple that we can detect
00:13:47.279 statically with I think it's using Erb lint and you can see over time going
00:13:52.360 right until about 2022 things were on the rise and that's when we started saying okay we need to make an effort about this and then really you know over
00:13:59.199 the course of two years we got a lot of these things significantly reduced so while being act clean and
00:14:05.480 reducing those violations doesn't mean that a page is accessible it's often a very significant improvement over a page
00:14:11.600 with ax errors and those graphs literally those graphs are what we brought to leadership that gave us more
00:14:18.519 funding to hire contractors to literally fill more engineering roles like that's what it took to go and say okay we need
00:14:26.240 you know two more two million more a year for engine ing budget to answer your questions from
00:14:33.000 last year so to sum it up you can't improve what you can't measure and even a
00:14:38.160 measurement that is a proxy for accessibility like a scanning can be really useful to demonstrate your progress you know we were obviously
00:14:43.839 making other changes besides just making our Pages acts clean um so I'd encourage you to go out and measure your acts
00:14:50.360 violations and then set some time aside to resolve them and continue to attct them over
00:14:56.920 time so now you have that measurement um and You' made your app a clean so
00:15:02.600 you've made some improvements you know how do you keep it that way uh this question reminds me of a favorite thought experiment does anyone know what
00:15:08.759 this ship represents okay tell me more what's the
00:15:15.519 ship of thesias so basically um to I won't give what the myal
00:15:23.199 background thank you here's this ship and um um it keeps
00:15:30.240 taking damage and they they're replacing pieces of it and the ship is always one
00:15:38.839 ship um but after a certain point every piece of the ship has been replaced and
00:15:47.720 none of the original ship is still there and so the sort of thought experiment is
00:15:54.600 is it the same ship and if not when did it stop being the same ship if replacing
00:16:00.279 well you did a better job than I would have basically the idea to summarize like I don't know if you could hear that the recording is that it's like if you
00:16:06.839 were to replace every piece of an object uh over time is it still the same object
00:16:12.279 at the end of the day in fact there's a git project called git ofthis that is really fun to run that will show you uh
00:16:19.120 it took five days to run on the two million commits in our code base but it uh it will show you the halflight like
00:16:25.040 the survival rate of all your code which is really cool um but that all being being said this really reminds me of
00:16:30.680 what Legacy software looks like in practice you know code gets moved around teams get reassigned constantly um
00:16:37.360 projects are put in maintenance mode you know people go on fraternity leave or they move on to other jobs so given all
00:16:43.240 those factors how do we make sure that if we like truly care about something that it doesn't fall through the cracks
00:16:48.360 and what we use is a a tool called a service catalog and those of you who have done security compliance work uh
00:16:54.399 specifically sock 2 might be aware of this um so we built this originally to our availability believe it or not to
00:17:00.680 just say that like okay for all the many uh areas of our product who's actually responsible for making sure that thing
00:17:06.559 is up or not um then when security became a thing we also use this as well and basically what it means is that like
00:17:13.280 for every chunk of our routes file effectively we group it together and we have a SLO hopefully four 9es hopefully
00:17:23.319 um an on call rotation and a chain of command up to a VP and we enforce that in code so we use
00:17:30.600 code owners uh we use a a we basically assign these GitHub teams to specific folders or files we'll also use
00:17:38.080 programmatic tags so we'll this is a simplified version but you might imagine that like you have a controller that actually for better for worse is split
00:17:45.559 between two Services we can use this macro to say map to service Repose for specific actions for example um with
00:17:52.679 this mean is that means is that every line of code has an owning service not an individual uh it's something that I
00:17:58.520 wish we didn't do in code owners on on GitHub where like you could assign a person like I think that's pretty unhealthy for a lot of companies to be
00:18:04.320 like okay this is Dan's code right like that's not good for you Dan and it's not good for everyone else um and forcing
00:18:11.240 every line of code to be owned by a service instead of a person really revealed a lot of bus factors in fact I
00:18:17.240 as part of going on leave it's often an audit to to go look at all the stuff that you have ownership for and make sure you are on a team of one uh which
00:18:24.640 is what actually happened to me and it it inspired us to hire some people that that split my ownership away from me
00:18:29.720 which is pretty cool um we also require playbooks for each service so like in order to get in this catalog you have to
00:18:35.679 have a Playbook so it's a way of us guarantee that we have some level of process um you know in documentation and
00:18:41.200 whatnot um I would say that like as we've scaled Beyond accessibility this is the single most important competence
00:18:47.520 we've added as an engineering organization like it's been a night and day like this is what I call like the adults walking into the room being like
00:18:53.960 okay everyone has to be responsible like yeah what so when I joined GitHub there
00:18:59.559 was one on call rotation for the whole company when we were 600 Engineers so once every 90 days I was the one person holding the L1 pager it's not that way
00:19:07.200 anymore and this and this is why um so uh amongst other things this
00:19:13.400 allows us to do really cool stuff like when you have an exception we can programmatically assign it right away so like for example we have an exception in
00:19:19.320 our search middleware and it goes immediately to the the team that owns that middleware uh without any like sort
00:19:25.960 of triage so like when we went from like one on call to like service specific on call we wanted to be able to we didn't
00:19:32.039 want to have to have one person triage request to the right on call so this allowed us to do it programmatically um so when we care
00:19:39.039 about any engineering capability now not just availability or security we give it a scorecard and then we incrementally
00:19:45.640 add services to that scorecard so we say like okay you are in compliance with the availability discipline the security
00:19:51.159 discipline um and these scorecards include criteria for whether a service is passing or failing it's a binary
00:19:58.200 measurement and if you're failing that leadership chain that same on call chain is alerted
00:20:04.200 and basically you have to stop work until you're in compliance in a lot of cases so for example we have an
00:20:10.720 accessibility compliance uh scorecard and this one is uh for automation so for some of those automation things we talked about this enforces that a
00:20:17.440 service is using our lenders and that there are no disables of the L rules so you get a a check mark on this if you
00:20:22.520 are passing acts basically uh we then track our scorecard participation over time and this is another way of showing
00:20:28.400 progress you can say that like okay we happen to have 220 services at GitHub and you can see this blue line is
00:20:35.080 just over you know a month we had an increase of like it was like you know 15 or 20 services that got in and got in
00:20:43.320 compliance so code team projects people they all come and go uh we should use
00:20:49.720 systems to prevent services from becoming unowned and a service catalog is one example of how you could do it I'm sure at smaller companies something
00:20:56.600 a little less formal might be fine
00:21:05.919 so at the end of the day uh the goal of any accessibility work is to make a product usable for as many people as
00:21:12.840 possible including people with disabilities it's not to pass a specific audit or be in compliance with Wick Haag
00:21:20.480 um and while we can get pretty far with Automation and tooling and the things I've talked about already there really
00:21:25.799 is no substitute for lived experience uh as a starting point we we uh taught
00:21:32.000 people who are cited uh across the company how to use screen readers to test their work we also set up a
00:21:37.720 Champions program which is a pretty common model where we basically took someone from each team and gave them more in-depth training so like for all
00:21:44.080 those 220 services for about I think like 50 or 60 of them that were the most critical we said okay you have to commit one engineer who's going to do 20 hours
00:21:50.520 of accessibility training uh that was more in-depth knowledge on screen readers in that case um and our goal is
00:21:56.279 basically to have one of those people trained up on as many teams that build UI as possible of which we have about of
00:22:01.880 those 220 it's probably ending being about 150 so to measure the impact of Champions We actually track their work
00:22:08.120 so we say okay how many issues did these people that we trained close so this was another graph that we put in front of leadership that said hey you know these
00:22:14.880 people that we trained have closed you know 450 issues and for reference we put the cost of closing accessibility issue
00:22:21.240 between five and $110,000 so that allows us to directly say dollars to Dollar people right that's a really important
00:22:28.360 thing to do just if they speak dollars you have to speak dollars to them um and
00:22:33.679 while we have several employees with live disability experience they are very small minority I could probably count
00:22:38.840 them on both hands uh in terms of people that have lived experience that specifically applies to like the screat
00:22:44.640 technology we're working on and because of that we've had to seek outside help so we hired a couple consultancies uh
00:22:51.120 We've hired petrological and Prime access Consulting they are super expensive but they are subject matter
00:22:56.480 experts so if you don't have the expertise you can't buy it um and it's often startling like I remember early on
00:23:03.120 when we worked with prime access they've worked they work with like NASA smithsonia and like all the big entities
00:23:08.799 and their consultant who's blind pulled open our homepage and brought us all to tears he's like I can't use it
00:23:16.320 sorry um he's like he couldn't sign up for an account like he was dead in the water
00:23:22.520 just going to Doom right like it was it was awful um but they aren't cheap
00:23:28.480 Consultants aren't cheap so a good starting point could be say have a screen reader hackathon where you know your team learns how to use screen
00:23:34.559 readers you know or passion week or something where you know you try and test as much of your app as you can as a
00:23:40.080 sighted user using a screen reader on the product side uh we've had
00:23:45.200 to do this process called accessibility conformance reports which uh use a specific template called the vpat or
00:23:51.840 voluntary product accessibility template and this is from section 508 and that's a lot of jargon for really something
00:23:58.000 simple which is that you have to document your accessibility issues for critical workflows in your product and
00:24:04.159 we publish ours publicly and this is often something that like larger companies have to do as part of this process and here's what it looks like
00:24:10.400 it's on accessibility. github.com you can go read all of our acrs today um
00:24:16.200 this for example shows that like when you go to the GitHub homepage and click the skip to main content link the screen
00:24:22.960 reader does not announce the main landmark that's one specific um screen
00:24:28.559 reader bug and this kind of disclosure is required by large customers because they want to understand what risk
00:24:34.880 they're taking on so you don't have to be perfect at accessibility to be quote unquote compliant what you really need
00:24:40.279 to do is you need to be aware you need to say okay these are problems we know we have and then the customer can decide
00:24:45.440 okay those are a deal break work for us in the case of some of our customers they literally take them to the people who work uh for them that have
00:24:51.320 disabilities and say are these things going to get in the way of you using GitHub and if not they'll buy the
00:24:56.360 software um we create these reports by navigating through about a dozen critical workflows that roughly line up
00:25:01.600 to the ones I talked about testing earlier very critically so we have automated testing for a lot of these very key uh workflows that we assess and
00:25:09.600 we have to do this every year and in in fact uh for more critical paths we have to do it about every six months and we
00:25:15.559 pay an outside firm uh to do this for us so we also track what services need
00:25:22.039 those audits using a scorecard in the service catalog you can see the pattern at this point it's like okay if it
00:25:27.760 matters if people need to be responsible and held accountable we put it in the service catalog so while I would guess that most
00:25:35.000 of you probably don't need this level of compliance I think the principle of this tool is very compelling despite the
00:25:40.320 jargon of of it um because this process forces us to identify the key
00:25:46.320 experiences in our products and to see if they are usable for people with disabilities and what we found is it's
00:25:52.679 easy to make the case to non-technical stakeholders that people with disabilities should be able to give us
00:25:57.720 money uh so you know because the last thing we want is for someone to be able to tell us that they can't do business with us
00:26:04.360 because of their disability and in fact if you look at like the kind of the Canon of accessibility lawsuits they all
00:26:11.039 basically hinge on being able to spend money or not that's why Ecommerce is like super prevailing because it's very
00:26:16.360 clear like oh I couldn't buy the shirt right it's pretty easy to be like could I with a screen reader go through and check out right and we have to make this
00:26:23.440 case because like as I've said this process requires a significant amount of money uh for a product of our scale so
00:26:28.760 for the low ballpark we're spending I would say over five and under $10 million per year on all of our
00:26:36.480 accessibility work as a company um that includes a seveners accessibility engineering team that's full-time a
00:26:43.279 threepers accessibil designed team each of those teams have a manager um and I
00:26:48.840 recognize this is a big hill to climb like I'm not expecting really I I would say that we're probably investing most
00:26:54.000 than more than most companies do um but there is something you all can do today
00:26:59.159 and I have some homework for you I have three tickets you can go file and get you can even do it right now some of you
00:27:04.919 are on your laptops so here's the first one as a screen reader user I can sign
00:27:10.000 up for a paid account as a screen oh sorry I can sign
00:27:15.120 up for an account and then as a screen reader user I can upgrade to a paid account uh so for example for us we use
00:27:21.159 a we still use a third party payment provider and like they control that UI code so like you could sign up for an
00:27:26.559 account but when you went into the iframe to actually enter your credit card details we had to work with them to actually get to the point where you
00:27:31.880 could complete the flow as a customer your customer doesn't know that implementation detail they just know whether they could actually sign
00:27:38.279 up and then the last one is as a screen reader user I can complete the workflow for my products most compelling use case
00:27:45.120 so think about the founder of your company when they went into an elevator and said this is what my pitch is that's
00:27:51.159 what you should be writing a screening your test for because if you can't deliver that core value that's where you're going to get into trouble really
00:27:56.640 quickly so for us this is like can I open a PR can I complete a code review
00:28:01.840 can I you know uh run tests with actions and see the result um can I merge a PR
00:28:09.480 uh and here's one way of doing it you can use tdd so one technique we've kind of
00:28:16.360 adopted here is using system tests for keyboard navigation because at the end of the day when you're using a syst of
00:28:21.960 Technology you're basically navigating the page with a keyboard um so what we did is we started by taking existing
00:28:27.240 system tests that clicked on UI elements and we rewrote them to use keyboard navigation so for example here's an
00:28:32.799 actual test this is the first test we converted from clicking to keyboard now and you don't need to read the source I
00:28:38.720 don't know why I put it on here but you go to the new releases page you select a tag that you pushed up and you click on
00:28:44.159 create uh release and you press the uh enter button in this case so what's Wild
00:28:49.559 here is that this is the first time we did this and we caught a screen reader bug on day one because this is what it
00:28:55.159 looks like when you run that test so as it turns out there was some
00:29:00.200 JavaScript that only triggered this lazily loaded uh portion of the drop down loading the tags
00:29:06.480 list if you had a cursor present on the window this was super hard to debug because the test kept failing and we
00:29:12.240 would Mouse into the into the uh page and it would just load and we're like great it works but then what we realized
00:29:18.159 is that if you let it sit for a while that was the bug it was that when there was no cursor present it never loaded so this is literally the first
00:29:25.120 time we tried this technique uh and we validated that the page was in deed broken for screw users we hit up actually our tetral consultant they were
00:29:31.640 like oh yeah it's never worked for me we're like why didn't you tell us um so besides automated tests like I
00:29:38.559 said you could you know getting people to use your application without a mouse Vim users are going to love to hear this
00:29:44.120 right like uh you know some some places they'll have no mouse Fridays just
00:29:49.360 Friday put your mouse away tape over your trackpad oh you know all these Vim users are like
00:29:56.159 finally my day is com waited all my life didn't know it was
00:30:01.240 going to be for screen readers but you know ultimately for lived experience to matter we need to
00:30:07.200 employ people with disabilities and then we need to give them power so in our case we hired a fantastic head of
00:30:13.279 accessibility who has Decades of experience uh in our legal department uh
00:30:18.640 who's a computer also computer science major and is also blind he uses a screen reader and he is in control of the
00:30:26.039 budget and can stop the line any in the company if he thinks that we aren't doing things the right way for
00:30:31.519 accessibility and I believe that that single move was the S was the most important thing that most important
00:30:38.640 decision any leadership at our company has made since I've been at the company was giving him
00:30:45.840 power because it'd be disingenous not to mention that this work is really hard like I said it's expensive it's also
00:30:52.200 timec consuming and I can guarantee you that it will slow you down but be Beyond
00:30:57.399 being the right thing to do our customers increasingly require it selling to the government and big
00:31:02.559 business often means more of this compliance burden and you can really see how it can limit
00:31:08.760 Innovation but if we don't pursue this work we run the very real risk of leaving those with disabilities behind
00:31:15.279 you know in this time of incredible technological progress you know GitHub we believe that like our software
00:31:21.279 enables people to improve the world in a really powerful way and we don't want to leave people with disabilities behind from that work so here's my challenge
00:31:28.799 for all of you measure your products accessibility own up to it and then give
00:31:34.559 people with lived experience the power to make it better thank
00:31:46.440 you for a couple of questions yeah time for a couple questions I want to say thank you to my peers these are some colleagues and uh Tim locally who are
00:31:53.240 peer reviewers for this any more questions or am I done giving talks here it was Microsoft
00:32:00.000 Microsoft so the qu sorry the question was was getting that leadership change in a Grassroots thing and no it was on high in fact honestly it's because we
00:32:06.559 weren't making enough progress on our own they were like okay we're going to appoint this person in your legal department and then this is their
00:32:12.240 responsibility and here's how much money they have on all this stuff sure so the question was uh from someone who works
00:32:17.320 at a university where accessibility compliance is probably actually the highest standard of most Industries um
00:32:22.760 how do you help individual developers like learn how to use screw neuters effectively and not run into blockers I
00:32:28.039 mean I'll tell you what we do which is we pay for training with DQ there's a lot of good resources online but DQ is
00:32:33.480 the uh where's the deck I can never get it right um they make acts and they have excellent resources that that go through
00:32:40.360 all this um that are hiring someone honestly like that's a lot of what we've done even with uh having the right
00:32:46.760 experts in house like we'll still do consultants and whatnot
00:32:51.960 yeah anyone else great thank you all
See Slides on hawksley.org
Joel Hawksley
@joelhawksley
Explore all talks recorded at Rocky Mountain Ruby 2024
+22