00:00:14.280
All right, so before we get started, I think it's common at conferences to provide a little bit of a warning if a talk has something not fun in it. So my talk is going to address a fire that happened here a couple of years ago, and there are some traumatic details involved. If that's not your thing, I might recommend checking out the breakfast downstairs. I’m going to be pretty gentle, but I figured it would be appropriate to mention it. In the summer of 2020, my wife Caitlyn, our dog Captain, and I moved into a home we had worked hard to obtain, which is where we planned to raise our family.
00:00:39.760
This is about five miles from here, in a town called Louisville, which is a suburb of Boulder. At that point in my life, moving to the suburbs was a dream. You know, looking at this photo, it feels almost like a Norman Rockwell painting. It makes me reflect on how comfortable many of us in the industry can be. This is a privileged life—having a dog, a wife, and a nice house in a beautiful area like Boulder County. To be honest, I had nothing to worry about; life was actually a little boring.
00:01:14.479
But that all changed about a year and a half later, at the very end of 2021. I was on a road trip down in San Diego, enjoying some time away from home, when I got a text message from the Boulder County Sheriff telling me I needed to leave my house. Thankfully, I was not home at the time; this was a little before 3:00 in the afternoon that day. About two minutes later, I started receiving notifications from the security camera on our front porch, triggered by falling ash.
00:01:59.399
I received a push notification every minute. I pulled up my phone and looked at my air quality monitor—it was not very good. The monitor assigns a score, and I had never seen red before. The number was 833, which is PM2.5, the standard measurement you see on your iPhone or similar devices. This number is almost the worst level ever observed on planet Earth in an outdoor setting; this was recorded inside my house.
00:02:43.440
That's because this is what was happening in my neighborhood. This house is about 100 yards from mine, just south of here. I never actually saw pictures from inside my neighborhood, and that’s true even to this day. The next morning, I looked on Twitter and saw a difficult video showing my neighborhood—about 100 of the 1,100 homes that burned down that afternoon. It was actually a few days before the National Guard allowed us back in. This is my wife and I standing in front of the same house showcased earlier.
00:03:36.280
One thing that really sticks out to me is that two weeks after our house burned down, I took my dog out for a walk and suddenly realized it had been two weeks since I had done this. I hadn't even thought about something that used to be a regular part of my routine just three or four days before. I started noticing many other changes—I found it challenging to focus on anything, I became really easily frustrated, and it was evident that technology I had relied on before was no longer useful to me.
00:04:06.480
I particularly remember trying to complete one of those CAPTCHAs; I literally could not do it. I was clicking on buses and kept missing one or clicking on something that was not in a bus. I also had trouble operating a password manager. What I soon learned, after getting help from a grief counselor at the Red Cross, is that significant emotional trauma can actually cause brain damage—temporary and permanent. This experience opened my eyes to the privilege I had before the disaster and changed my perspective on the world in ways I hadn’t anticipated.
00:05:07.680
Today, I want to talk about accessibility, which has many definitions, but I’d like to provide a definition for our conversation. I really like this one from the Interaction Design Foundation: accessibility is the concept of whether a product or service can be used by everyone, however they encounter it. I think that’s a nice way to describe the inclusivity of accessibility. In the past, like many people, I imagined individuals with disabilities were very visible, like people using wheelchairs or walking with canes. Since my experience, I’ve learned that disabilities come in many forms, many of which are invisible.
00:06:09.760
One framework for describing this is by looking at situational, temporary, and permanent disabilities. For example, a permanent touch disability could be having one arm, as someone in our local Ruby community does. A temporary touch disability could be having a broken arm, while a situational touch disability might be when I'm carrying my baby around the house and can only use one hand, or when my hands are full carrying groceries into the house. A permanent hearing disability could mean being deaf, while a temporary one might be having an ear infection, and a situational disability could be working in a loud environment or being in a bar.
00:07:10.400
So when I couldn't complete CAPTCHAs, what I experienced was a temporary cognitive disability. Thankfully, it was not permanent; I can click on buses now. Throughout my work in accessibility, there are various guidelines and standards to follow—many of which you’ve probably heard of, like WCAG or Section 508. However, in practice, you just need to understand that accessibility means making sure that the things we build work with assistive technologies.
00:07:57.920
I won’t get into a ton of detail, since assistive technology takes on thousands of forms. At my job, we primarily focus on screen readers. These are tools that read the screen aloud and allow users to navigate with a keyboard. For example, if a user is looking at a GitHub profile page, the Mac OS screen reader, VoiceOver, will announce each section of the page as the user navigates with their keyboard. Screen readers effectively turn web pages back into code by converting them into a navigable tree structure.
00:08:59.600
You can observe this functionality in practice. If you go into the Chrome DevTools and click on the accessibility tab, you can view the Chrome accessibility tree. This shows the structure of a page that a screen reader navigates. Today, I'm going to discuss how we've approached improving accessibility for people using screen readers at GitHub. I will share details about three key areas: automated scanning, changing how we build forms, and a new UI development paradigm we are calling preview-driven development.
00:09:28.640
But first, let me introduce myself. My name is Joel Hawksley, and I’m a staff engineer at GitHub. I work on various UI-related aspects of the company. While I am probably the closest thing we have to a UI architect, I'm not very close to that title. Currently, accessibility is a significant focus for GitHub, and when I talk about my work there, I believe it’s helpful to provide context about the company’s size.
00:09:56.959
As of now, GitHub has about 4,000 employees, and believe it or not, we are still a Ruby on Rails monolith. You may have heard otherwise, but that is the reality. We serve billions of requests per day; I couldn't give you the exact number, but it's in the billions, coming from our Rails monolith. We also have approximately 1,400 Rails controllers. It's fascinating that this number has increased by 25% since last year. When people ask if Rails is dead, I can confidently say that GitHub grew by 25% in our Rails framework last year. Rails is far from dead.
00:10:37.920
I love emphasizing this stat in every talk I give about GitHub, as it demonstrates our commitment to Rails. That 25% increase means we added 350 controllers in just one year, and you can imagine how challenging it is to maintain a code base that's about 15 years old with a couple million lines of Ruby. Another helpful graph illustrates the number of lines of ERB in our code base over time. As you can see, there has been a steep increase in lines in the code base since the first commit, which was made in late 2007.
00:11:05.599
You might think, 'Hasn't GitHub figured everything out by now? The product is good, right?' The reality is that it's getting much bigger, which complicates things. I find it important to give context regarding some decisions we've made about accessibility and how GitHub works, especially considering that GitHub is in a rather unique position.
00:11:42.600
For the first six years of GitHub’s existence, there was something unusual about the company. So, does anyone know what was peculiar about it? Silence? Well, I'll reveal that GitHub had no managers for the first six years. This absence of management was indeed odd. Another interesting aspect of this situation was reflected in the architecture of the GitHub headquarters.
00:12:17.240
If you were to visit our headquarters in San Francisco, you would notice that the entrance was a replica of the Oval Office from the White House. There was also a similar entrance in our Boulder office until the pandemic. One notable feature of this entrance was a rug that stated the united meritocracy of GitHub. For years, GitHub operated with a mindset some have termed 'cooking for chefs.' This meant that, since we all were software developers, we assumed we knew what GitHub should be, allowing us to build whatever we felt was right.
00:12:53.519
We believed our customers would likely agree with our ideas because we shared similar backgrounds with them. However, I honestly don't believe GitHub would have survived without managers if this mindset had persisted. This approach had its downsides; I am aware of instances where we regrettably turned down deals worth at least $10 million just because we couldn't find engineers who could fulfill the customer's requirements.
00:13:36.679
But many things have changed since then. Without sounding too much like a GitHub spokesperson, one of the tenets we uphold internally is to make GitHub a home for all developers. Our aim is to continuously expand this definition of 'all.' We firmly believe that people with disabilities should benefit from and contribute to the advancement of human progress. This focus is critical, as we recognize the essential role of technology in shaping the future.
00:14:05.120
We realize if people with disabilities cannot be involved in the conversation or the technology-building process, they will be excluded from that future. These objectives are significant, particularly as our application is growing at an ever-increasing rate. For accessibility, this means we cannot simply go through GitHub’s thousands of unique pages and fix each one to ensure they are accessible. Even if we attempted that, we would immediately introduce regressions.
00:15:07.920
To achieve our goals, we quickly understood that we needed strong tools. One of these tools is automated accessibility scanning. If you remember one thing from this talk, I hope it is this: poor accessibility never breaks CI within a traditional application stack. One thing that has always concerned me about this industry is that many of the best practices I learned before working on accessibility did not lead to accessible experiences.
00:15:34.080
Even though we implemented automated accessibility checks in our CI pipeline, they are still far from perfect. I can optimistically say that between 30% and 50% of accessibility issues can be detected through automated means. Let me illustrate this. When we have an image on our application, we require that it has alt text, which is accessibility 101. If a screen reader user cannot see the image, they need to know what it represents.
00:16:06.480
You might write an alt text saying, 'My picture is of a cat sitting on a rock.' However, if it’s actually an image of a dog, getting a computer to identify that error is quite difficult. I’ve seen people attempt to use AI object recognition to address this issue, but it still falls short. The complexities multiply with graphic design; we use various visual techniques to communicate information, which are not just words and images.
00:16:43.360
For instance, positioning items in two columns instead of a large group communicates differences, but someone who is visually impaired cannot perceive that information. I honestly do not know how to create technology that would catch those kinds of accessibility problems. Despite all these caveats, automated scanning is still invaluable, and we primarily use a tool called Axe. This has become the industry standard.
00:17:14.480
How many here are familiar with Axe? That’s great! I’m glad I’m giving this talk because Axe is fantastic. It covers a specific class of accessibility errors that help make applications more accessible. You can install it in various ways, including as a browser plugin to highlight violations in DevTools. For instance, when I loaded Meetup.com recently, I saw it had 48 accessibility issues.
00:18:00.559
Axe lists the specific violations, such as images must have alternative text. The most effective implementation we've found is running Axe as a JavaScript snippet on our development page. This highlights violations visually in the application. It means that while building something, you'll see any errors, and they'll log in the console. At one point, we even had it set up to trigger an alert for any Axe error to encourage quick fixes.
00:18:39.919
Additionally, we allow staff members to add a flag to their accounts, so they receive alerts about these errors when using GitHub in production. We also run a suite in our end-to-end testing environment, running accessibility checks with Axe after every production deploy. We also create custom Axe rules, recognizing that many applications have specific UI patterns that could lead to issues.
00:19:00.880
For instance, on GitHub, our tooltips are custom and not the standard browser ones. Some developers incorrectly decided to place links in these tooltips, which is highly inaccessible. Therefore, we have a custom rule stating that tooltips should only contain text, preventing this from occurring. Unfortunately, despite the successful rollout of Axe at a significant scale, it has also raised several sticky issues.
00:19:52.679
In some cases, we've encountered parts of our application that have fundamental accessibility barriers. This is challenging to discuss because accessibility is often perceived as something that can be resolved with minor changes to a page. I’m talking about scenarios where we’ve had to redesign entire workflows—spanning multiple pages—from scratch due to accessibility issues.
00:20:28.120
For example, drag-and-drop functionality poses a significant challenge. Look at GitHub Projects; we released a new version recently. Think about how a user would take a card and move it up or down in a column using only their keyboard. Would anyone like to share how they would accomplish that? Yes, a lot of tabbing and hoping that your screen reader announces what’s going on. It’s almost impossible for that to be successful without clear navigation.
00:21:02.120
You can imagine that an automated scanner won't catch this either. Despite the downsides, Axe remains an excellent starting point. If you were to leave today, head back to your companies, and install Axe, fixing all the errors, you would accomplish more than 99% of people out there, thereby improving your application’s accessibility.
00:21:33.440
Generally, we start with Axe whenever trying to make a page accessible since it helps eliminate the obvious errors in our UI. It also gives us insight into the extent of other issues we will need to address. Another critical tool in our accessibility work has been transforming how we work with forms. I don’t need to explain to this crowd that forms are essential in Ruby on Rails.
00:22:08.640
If you go back to the original 'Build-a-Blog in 15 Minutes' demo from almost 18 years ago, most of the demo involved building forms. Even now, looking back at the demo from 'Hotwire,' it largely focuses on forms. I believe Rails should excel in creating forms since we have excellent tools like form_tag, form_for, and form_with.
00:22:46.160
When we look at forms, I'll reference an example from the Rails documentation. Here, the example demonstrates form_with in your template and what it actually outputs. This example makes it clear that it’s primarily a mapping from Ruby calls to DOM nodes, simplifying the complexity significantly and providing tools for adding select options to forms. However, it is important to note that this isn’t accessible by default.
00:23:24.799
If we look at this example code, we see that the form input, the text field created by form.text_field, indeed has an associated label. They have that matching query symbol concern. This example is great because it is accessible, complying with one of the Axe rules that states you must programmatically associate labels with all form controls, where 'all' is emphasized. The recommended practice is to use the label element with an explicit association using the for and id attributes.
00:24:07.679
However, the dilemma is that many developers need to remember to do this, and in my experience, not many do. According to Axe’s rule, all of our form controls indeed need labels, but it is just an option in Rails. Drew knows well that we discussed this last night, but I’ll make one book recommendation today.
00:24:30.039
My favorite software engineering book is 'A Philosophy of Software Design,' which I consider having the best programming book cover ever. It discusses how to untangle spaghetti code, and one chapter that resonated with me was titled, 'Define Errors Out of Existence.' The premise is straightforward; you can substantially enhance your software by making invalid options impossible. While working on forms at our scale, we aimed at finding ways to define specific accessibility errors out of existence.
00:25:22.679
Luckily, we hired a new engineer eager to tackle a fresh challenge. I asked Cameron what it would look like if we made our Rails form builder accessible by default. He created a new DSL, an application form that felt right, constructed a method to create text fields, and ensured labels were automatically generated. This solution enabled us to create input and label tags that linked correctly, thereby satisfying the Axe rule 100% of the time.
00:25:57.480
What we did with this approach was make the occurrence of Axe errors difficult, if not impossible, by creating better abstractions for form building. While it might not be feasible to apply this method to every Axe violation, we've identified an extensive list, developing abstractions that are accessible by default. This experience taught us that by concentrating on creating these accessible abstractions, we may have found an answer to the long-standing question of what defines a good UI component.
00:26:42.120
In our design system, as with many, we have an avatar component that appears countless times throughout GitHub. This avatar often links to user profile pages. When clicked, it navigates there, and if you hover over it, a hover card displays additional information about the user. The challenge arises as we often place this avatar next to a text link to the user profile. If you’re using a screen reader, you might find this situation redundant.
00:27:28.240
As you tab through these elements, the screen reader might announce 'alt text user Joel Hawksley,' and if you trigger the hover card, it could reiterate the same name. Duplicate information for screen reader users can be a taxing experience and presents a significant problem. To address this, we created a new component called a nameplate, incorporating an avatar alongside the text link, ensuring that the combination provides a smooth and accessible experience for screen readers.
00:28:09.600
I won’t say we’ve rolled it out everywhere yet, but we’ve implemented it across many parts of the application. The full framework for these forms is available in the Primer View components repository, and it's open source. The last topic I’d like to address is a concept I’m calling preview-driven development. If you’re deeply involved in React work, this notion might not come as a surprise.
00:28:56.160
We have a long-established feature in Rails called Action Mailer previews. This allows you to view your email layouts in a local environment without needing a fake mailer. When we build our UI components, we also create previews for them. An example would be rendering a button in isolation, like our danger button. Generally, our previews look like mailer previews, with their underlying control features. For button components, we might have different previews showcasing color schemes and functions.
00:29:47.280
We use these previews in our tests, where we have helpers that render the preview, integrating them into Capybara, which allows us to run assertions without a browser. Conversely, if you want to run a system test, you use the 'visit preview' command instead of 'render preview.' This innovative workflow has begun to blur the lines between writing code for tests and writing for local development.
00:30:36.000
Consequently, we have consolidated our test case examples into previews, leading to easier debugging of UI tests. When encountering an issue, you can simply open the preview in a browser rather than delving deeper into failing test cases. If we look back at that button test, say we misspell the selector, it will fail, but we can open the preview URL directly in our browser, inspect the element, and utilize developer tools.
00:31:29.360
Additionally, this makes our component discovery much easier. With over 1,500 people committing to our monolith, it’s common for two individuals or teams to develop similar components, which can be awkward. To mitigate this, we use a tool called Lookbook that organizes our previews, creating a functional component directory. This is reminiscent of Storybook in React, where Lookbook is a reimplementation using Hotwire.
00:32:11.200
Lookbook does more than just connect our development environment to our testing environment; it also generates documentation. This encourages us to write practical test cases, as previews from those tests become the UI documentation. In fact, this method has proven so effective that when we recently rebuilt the Primer design system website, we didn’t even add handwritten documentation. We simply directed users to explore the previews, as they are kept up to date by the test suite.
00:32:58.720
I think the most important aspect of this workflow, particularly regarding accessibility, is that developers are now guided to run their components through Axe. We’ve incorporated this into our Lookbook configuration, meaning that while inspecting a component in Lookbook, developers can see all the Axe results. Furthermore, we iteratively run Axe against these previews in our CI during every build.
00:33:36.160
This workflow exemplifies how we can integrate ideas from the React ecosystem into Rails while enhancing accessibility within the Rails UI development process. In the context of accessibility, there's a concept known as Universal Design. Does anyone here know what Universal Design is? Well, it refers to the idea that when we create something usable for people with disabilities, these accommodations also benefit everyone.
00:34:29.680
For example, curb cuts were initially designed for wheelchair users, but now, new parents push strollers or someone who has trouble lifting their feet find them equally helpful. We can learn a lot from this mindset—what might Universal Design look like in software? In a sense, SSO (Single Sign-On) can act as an accessibility feature. When I am experiencing high emotional stress, I can utilize SSO; my phone looks at my face, and I'm in—no need to click on CAPTCHAs or struggle with remembering passwords.
00:35:24.800
I used to scoff at the idea of SSO, but I now appreciate it much more than ever, especially when it alleviates that burden in stressful circumstances. Ultimately, the bigger lesson I've learned while working through accessibility issues is that it represents a significant class of problems that reflect larger blind spots we as able-bodied, privileged software developers have.
00:36:01.240
This reminds me of something Donald Rumsfeld famously articulated: 'We know there are known unknowns, that is to say we know there are some things that we do not know. But there are also unknown unknowns—the ones we don't know we don't know.' Throughout history, it is often the unknown unknowns that present the most significant challenges.
00:36:47.560
Let me provide a practical example of these unknown unknowns. Even among our customer base at GitHub, which leans toward users with more advanced hardware, their experiences are vastly different from ours. A benchmark shared by DHH on Twitter indicated that late last year, GitHub issues tested on an iPhone 13 Pro had performance capabilities vastly superior to the fastest Android phone at the time.
00:37:35.320
This discrepancy means our development experience is at a different performance level from what our customers using Android experience. For security reasons, we only use iPhones for our processes. This creates significant differences in customer experience perception, particularly regarding request latency.
00:37:53.080
Most GitHub traffic is served from the US East Coast, meaning our US-based staff doesn't experience the same lag that customers in Australia might. Although we have virtual points of presence to mitigate this to some extent, it disproportionately affects single-page applications and operations like WebSockets.
00:38:26.000
How can we address these blind spots and discover the unknown unknowns? One effective way is to build empathy into our engineering practices. It begins with putting ourselves in the shoes of people who are different from us. The more different, the better.
00:38:54.560
Thank you.
00:39:05.800
To end on a positive note, this is a picture I took earlier this week with my drone. It shows the area surrounding my home, which burned down. Approximately 60% of those lots are currently being rebuilt; mine is in the top right corner.
00:39:31.160
Any questions?
00:40:10.960
Yes, we do struggle with accessibility. I mean this very seriously when I say that, as an industry, we are falling short in this area. What we're doing at GitHub isn’t about excelling; it's simply about improving from a poor state. The industry standard remains disheartening; we can learn from our mistakes.
00:40:36.560
We’ve had to employ people with disabilities to help us understand the accessibility flaws in our software. I have, at times, been moved to tears watching someone grappling to use software I’ve helped develop. If there’s a takeaway from this, it’s to observe how others interact with your software, particularly those with disabilities. Watching them struggle to remember login methods or capturing their frustration can be enlightening. How about the question regarding accessibility of emojis? The answer is—it depends. They are becoming more accessible as browsers improve, but our practice is to limit their use and ensure alternative text is always provided.
00:41:36.640
As for how we champion accessibility at GitHub, I’ll elaborate on that in next year's talk. To give you a brief preview, we were sued over our accessibility shortcomings. Legal precedents are plentiful; in fact, I’m surprised someone hasn’t developed an automated vulnerability scanner to file lawsuits against the most common accessibility infractions at websites. This is something we should keep in mind, as there is a real legal risk associated with neglecting accessibility.
00:42:55.960
We employ a head of accessibility who is blind and a lawyer, and that has made an important difference in navigating these challenges. By framing accessibility concerns within business risks, we can highlight the potential for legal repercussions. To make incremental progress, we implemented an accessibility scanner framework to run checks across our GitHub network. Thus, it’s prudent for everyone to take the opportunity to implement automated accessibility checks in their public-facing applications. For the simplest start, ensure your CI pipeline is running Axe and returning green lights. The addressability of this issue to management could get the necessary resources allocated for improvements.
00:43:39.080
Oh, Axe is a tool developed by Deque; it's free to use and widely regarded as the industry standard. If it fits your workflow, consider integrating it as it serves to improve accessibility effortlessly. There are other options, but Axe is incredibly solid.
00:43:53.200
For mobile applications, I'm currently on maternity leave and don’t have the latest updates. We plan to dive deeper into this area as part of our extended efforts to improve accessibility uniformly. Generally, iOS frameworks, particularly Swift UI, have better accessibility accommodations integrated into them than web applications. That allows for easier implementation, although it remains an entirely different process nonetheless.
00:44:18.160
Thank you for your attention, everyone.