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

00:00:10.200 Hello and welcome to our second session of the day: 'How to make your application accessible (and keep it that way!)' by Joel Hawksley. Joel is a staff software engineer at GitHub, working on user interface architecture and strategy.

00:00:23.199 Please welcome Joel to the stage.

00:00:36.559 I feel like everyone is so welcoming and caring, which I think is a hallmark of the Ruby Community. I don't know about you, but as programmers, we're often stereotyped as being out of touch. I know I certainly feel that way from my friends and family. However, it’s really cool how the Ruby Community identifies itself with inclusivity.

00:01:13.960 On that note, I have some bad news. As an industry, the products we build are often incredibly unwelcoming, particularly to people with disabilities. Depending on who you ask, between 70% and 99% of the internet is effectively unusable to people who are blind. But I also have some good news: we can do better, and I'm here to show you how.

00:01:44.439 We at GitHub have been working hard over the last couple of years to make our platform more usable for people with disabilities. We've learned a lot along the way, and I’d like to share what has gone well, what hasn't, and how you can implement the good practices in your own company.

00:02:03.920 My name is Joel, and as I mentioned, I'm a Staff Engineer at GitHub. I've been speaking at RailsConf for six years, and it's great to be here in Detroit with all of you. My talk today is a continuation of a talk I gave last year, so I’ll provide a brief summary for context.

00:02:36.200 Last year, I shared how we use AX, an automated accessibility scanner which many of you here may have heard of. This tool helps automatically surface accessibility issues in our application. For instance, when developers work on GitHub, they see red outlines around elements with AX errors.

00:02:54.000 I also explained how we use custom Rails form builders to eliminate certain accessibility errors and discussed a tool called Lookbook, which you can think of as Storybook but tailored for Rails first architecture. We use Lookbook's built-in accessibility tools to identify accessibility errors in the UI development process. I thought my last talk was well-received, but the Q&A revealed that I might not have fully addressed what our audience was really concerned about.

00:03:34.360 The central questions seemed to revolve around whether these accessibility initiatives would scale. Specifically, how do we get leadership to care about making more than just one accessible page—how do we ensure that massive applications, like GitHub’s, remain accessible? And how do we keep it that way?

00:04:10.000 Before proceeding, how many of you work at companies with an accessibility goal of some kind? Wow, that’s about half of you! Last year, that number was significantly lower. How many of you have worked on your company's accessibility goals? About a quarter, great!

00:04:27.600 Over the years, GitHub has worked to enhance accessibility, although efforts were previously haphazard and lacked coordinated goals until 2018 when Microsoft acquired us. This acquisition generated skepticism about its impact, but one of the significant results has been Microsoft's commitment to accessibility.

00:04:51.199 Many large corporations and governments value accessibility, and as an inclusive community, it’s our shared belief that making our products accessible is the right thing to do.

00:05:17.320 Today, I will focus on the pragmatic, capitalistic reasons for ensuring accessibility. First, accessibility represents a legal risk. I’m not a lawyer, but I've learned from my colleagues at GitHub that failing to accommodate accessibility can expose companies to significant legal repercussions. Many firms have been pressured legally over accessibility issues, and GitHub has faced this too.

00:05:54.560 Legal pressure has historically been a tool to push accessibility, not just for digital access but for physical access as well. For decades, wheelchair users have found that suing businesses lacking accessibility features, like proper ramps, has been one of the most effective methods for making their environments accessible. We’re seeing a similar trend in web applications. According to Forbes, there were more than twice as many digital accessibility lawsuits from 2018 to 2023. It's astonishing that over 80% of the top 500 e-commerce websites received a digital accessibility lawsuit during that same timeframe.

00:06:39.920 Our primary goal at GitHub is to ensure that our user experience works for individuals who rely on assistive technology. In practice, that means adhering to the Web Content Accessibility Guidelines (WCAG), which many governments and large organizations utilize to establish a standard for digital accessibility.

00:07:18.600 It’s essential to share a snapshot of our company’s context. We have over 4,000 employees, with more than 1,500 being engineers. Importantly, we are still a Ruby on Rails monolith with a substantial application structure. Whenever you visit GitHub.com or make API requests, nearly all those requests go directly into Rails. Uniquely to our application, we handle over 2,000 individual pages, which I've heard is significantly different from other companies of our size.

00:08:02.240 To gauge how accessible features are, understanding the engineering scales involved in your company is crucial.

00:08:13.319 In summary, our plan to ensure accessibility boils down to three key elements: measurement, durable ownership, and lived experience. A few years ago, when I joined the design organization as an engineer and reported to my colleague Diana, we often faced the challenge of measuring our efforts effectively. I recalled something she said about having various aspects to refactor in large codebases and needing a clear sense of completion.

00:08:59.959 One valuable piece of advice from a book titled 'How to Measure Anything' emphasizes that measurement’s value lies in determining whether goals were met—precision is less important. For example, our tests are binary measurements; they inform us whether we've succeeded or failed, which is still valuable data.

00:10:02.680 When we began addressing accessibility at a company-wide scale, we first needed to measure the problem. We started with our DNS, attempting to find clever ways to manage it under version control. Our DNS repository listed the approximately 100 public-facing domains we had, and I authored a script that ran accessibility scans across all of them. Our AX report showed that we had about 18 accessibility violations for the root pages.

00:10:50.240 What’s impressive is that the industry average is approximately 55 violations for a home page among the top million websites, meaning we’re doing relatively well at about one-third of that average. However, even one AX violation can make a page difficult for a user with assistive technology. We also scanned our design system documentation, which initially had around 50 violations. After a focused effort, we managed to bring that number down to zero.

00:12:15.320 We included AX scanning within our system tests across key scenarios for GitHub, tracking long-term progress on crucial accessibility rules. We implemented tactics to analyze our historical data, which enabled us to retroactively assess AX violations over several years. By utilizing this data, we could demonstrate to leadership how meaningful progress had been made on our accessibility goals.

00:13:06.680 In summary, you cannot improve what you cannot measure. While simple measurements like AX scanning may seem inadequate, they can effectively demonstrate the value of accessibility work to non-technical stakeholders. I'd encourage you to start measuring AX violations in your application and develop time to address them.

00:13:29.080 Having established some measurement, let’s consider how to maintain our efforts in accessibility. This issue reminds me of the philosophical thought experiment, the Ship of Theseus.

00:13:48.000 The Ship of Theseus suggests that if you gradually replace parts of the ship, is it still the same ship? In a coding context, as teams rotate and personnel change, ensuring responsibility for accessibility doesn't fall through the cracks becomes essential. This leads us into a significant organizational concern of maintaining accountability for our systems.

00:14:29.760 We use a service catalog to track availability and security across our systems. Essentially, we market GitHub by category, and we have designated duty rotations for different disciplines for our products. Each aspect of our application has associated teams, which include a vice president overseeing that area. Perhaps the most crucial aspect of our approach is ensuring that every line of code is owned by a team rather than an individual.

00:15:49.280 In two years, we've assigned teams to own every file in GitHub, ensuring they have staff and on-call rotations. This strategy not only highlighted potential vulnerabilities in our system but also helped us identify missing documentation concerning on-call protocols. This approach, inspired by Microsoft’s expertise, has been pivotal since our acquisition.

00:16:40.640 From a technical standpoint, we’ve developed integrations, ensuring that when exceptions arise, we can directly associate them with the responsible team thanks to our service ownership definitions.

00:17:29.920 Accessibility is a top priority alongside availability and security at GitHub. We're implementing scorecards that enforce the use of accessibility linters on our projects, which gives a clear picture of team participation and places accountability on developers.

00:18:23.000 One crucial aspect of sustaining our accessibility work is lived experience. We've initiated programs to teach our sighted developers how to use screen readers. Additionally, we’ve implemented a Champions program, where trained individuals on 60 different product teams receive about 20 hours of accessibility training, elevating their understanding of how to navigate using screen readers.

00:19:39.200 We've been tracking how many accessibility issues are closed by these champions, and over time, we've seen a significant increase. However, we recognize that good accessibility consultants are crucial and often hard to find unless your budget allows hiring specialized individuals. We've engaged these services for direct input from users with disabilities, which has been eye-opening.

00:20:57.920 Although it may come at a higher cost, leveraging lived experiences is invaluable. It's essential to have individuals using our software who can provide direct feedback about their experiences. Watching someone navigate through our application with a screen reader for the first time was profoundly moving. If you take away anything today, it's that you need people using your software, and they must be empowered to share their experiences.

00:21:54.880 We continue to hold hackathons where participants use screen readers for testing. Along with other initiatives, we produce Accessibility Conformance Reports (ACRs) that leverage industry-standard templates to document compliance with Section 508 regulations. This documentation guides us in identifying problems and helps us improve overall accessibility.

00:23:05.640 Publishing our ACRs helps convey our commitment to accessibility, which is essential as many clients now require transparency about accessibility issues before purchasing software. Even if companies can’t resolve all issues, documenting them is essential for establishing trust and transparency with clients.

00:24:24.800 Using a letter grading system, we assess our accessibility performance, aiming for essential workflows and updating our audits accordingly. It's imperative to conduct regular assessments to keep pace with changes in your application. Frequent audits, especially on areas of major change, are vital.

00:25:05.560 What I've shared so far may seem heavy on compliance, but the concept of the ACR is critical. It forces us to identify key experiences that should be available to users with disabilities. Moreover, it bridges the gap between technical work and product management, simplifying how we discuss the need for accessible design with leadership.

00:26:05.200 Ultimately, our customers require accessible software, and we must keep our applications usable to everyone. The financial implications of accessibility efforts are considerable; I estimate that GitHub spends around several million each year on accessibility initiatives, including personnel and consulting services.

00:27:15.720 I understand that implementing an effective accessibility program requires significant resources, but I encourage all of you to take the first steps today. Start by defining user stories that incorporate accessibility.

00:28:16.120 For instance, consider stories like, 'As a screen reader user, I can sign in and create an account.' You’ll also want to test whether upgrading to a paid account is accessible for users relying on assistive technology. Identify your product’s core functionalities that need to work with screen reading technology.

00:29:23.440 Using Test-Driven Development (TDD) can improve your application. By adopting system tests that work only with keyboard navigation and combining them with accessibility tools, you can catch a large percentage of accessibility issues.

00:30:10.480 For example, we write our system tests in JavaScript to establish keyboard interactions. During an initial conversion, a team member discovered a significant bug triggered by mouse events not being fired when a cursor was not present. This emphasizes the importance of keyboard navigation testing to surface accessibility issues.

00:31:00.240 To summarize, avoid reliance solely on automation for accessibility. Manual testing through keyboard-only navigation often uncovers more problems, particularly when integrating different codes together.

00:31:50.640 For accessibility initiatives to be successful, we must employ individuals with disabilities and empower them as leaders in the process.

00:32:20.640 We have made progress at GitHub due in part to hiring Ed Summers, a long-time advocate for accessibility, who brings invaluable experience to our program.”

00:33:01.280 It is essential to recognize that fostering accessibility requires commitment. It’s a challenging journey that might introduce further obstacles in the short term, but it should not hinder innovation.

00:34:18.520 Ultimately, we must strive to be inclusive and supportive of users with disabilities as we adapt to a more technologically advanced world. I challenge all of you to assess your products' accessibility and communicate it appropriately!

00:35:05.560 Thank you for your time, and I also want to extend my gratitude to my peer reviewers who helped refine this talk: Kendall, Eric, Kate, Lindsay, Tim, and Jonathan.

00:36:02.000 I have about six minutes left for questions or potential ideas for next year's talk. What does pushback from leadership look like regarding accessibility efforts?

00:36:21.280 Feedback has come from both ends, whether from leadership asking to meet minimal requirements or from teams feeling overwhelmed by the amount of work required to meet compliance objectives. We must craft measurements and goals everyone can agree upon to navigate these challenges. Balancing compliance and workload is crucial.

00:37:31.480 I also find it essential to differentiate between web and mobile insights as mobile applications tend to receive more scrutiny from users with disabilities.

00:38:02.400 Tooling needs to go beyond findings post-development; we can help developers prioritize accessibility as part of the development process through improved training, workflows, and integration into existing coding practices. In closing, I appreciate the audience for your questions and engagement.

00:39:12.240 Thank you all for being here, and I’ll be available for further questions as well! I look forward to continuing this important conversation around accessibility.