Relaunching Reactime: Updates and a New Accessibility Feature!
Bringing Reactime into the accessible world. An already successful tool takes the leap into accessibility.
Co-authored by: Amy Yang, Oliver Cho, Jesse Guerrero
What is Reactime?
As the second most popular web framework of 2023, we can confidently rank React as our most popular frontend framework today. And with great power comes great responsibility (and irresponsibility, as the case may be): bugs! Sometimes those bugs are simple syntax errors, but often they’re so complex that it requires you to have a good grasp of your application’s component architecture. As the scale and complexity of your React application grows, visualizing that by yourself becomes tricky if not impossible.
Enter Reactime: an innovative, time travel debugging tool specifically designed for React applications. No longer will you have to try and imagine the relationship between your components or remember what your app looked like 2 state changes ago. Reactime offers a fresh approach to debugging by enabling time travel through the application’s state history. It does this with a robust suite of features including a component map that boasts a dynamic visualization of the application’s component hierarchy, web metrics on how your application is currently executing, visualization of your app’s React Fiber tree, and much more.
Here comes version 24.0!
If it’s so amazing, you probably ask, why is there a version 24.0 being released? Fabulous question.
The feature
Accessibility debugging!
Why we care
Accessibility is still a newer topic in web development and the pervasive principle that “no ARIA is better than bad ARIA” makes it that much more intimidating for developers to attempt implementing it. But no accessibility in a web application is not only exclusionary, it unnecessarily limits a company’s user base. In fact, it’s been shown that accessible design improves user experience for everyone, not just those with disabilities.
What we did
So now that we are all in agreement that accessibility is a must, how do we avoid that tricky trap of implementing it poorly, and making the UX/UI of our sites less navigable for everyone? Well, you could use Reactime v. 24.0’s accessibility tab, for one!
When we first embarked on building an accessibility debugging tool, we considered creating a feature that would flag ARIA violations, much like a lot of other tools on the market like Axe. But there were two reasons we decided against this. First, Accessibility is still considered extremely difficult to execute well because it often requires human involvement, as there are very few rules that will apply in every context. For example, in some cases, you would want an ARIA label that announces a state change that would not otherwise be apparent to a screen reader, and in other instances, too many notifications of this kind overload the user when a simple, semantically named, built-in HTML element would have done the job. Basically, there is no rule that is always true. That’s why accessibility requires a lot of human testing.
For this reason, we wanted to make our feature more process-oriented. Much like traditional testing, leaving accessibility for last in the DX makes it far more painful and less effective. This testing procrastination used to be a huge problem in the field of software engineering until companies began implementing shift-left testing. Accessibility is still in that End 2 End phase for several reasons, but one major barrier to improving accessibility is a lack of widespread knowledge about how to incorporate it effectively into the development process. So, what would be useful to developers so they can more accurately perform their accessibility-oriented development? We went with a tab that shows the current state of the target app’s components as a screen reader would interpret it.
How we did it
We created an accessibility tab that shows a map of the nodes on Chrome DevTool’s accessibility tree! For context, Chrome DevTools has a feature called the accessibility tree that shows us an HTML approximation of what assistive technology would be reading from a given page. We decided to grab that tree using the chrome.debugger API, then filtered the nodes by pruning the incoming accessibility tree and used those pruned nodes as the basis for a new component map in the style of version 23.0’s component map. We initialized the tab using React Router’s NavLink. Then, within the tab, we leveraged visx’s Link Types visualization and D3’s algorithms to organize those nodes based on their parent/child relationships to one another. (D3’s algorithms contribute complex mathematics and functionality needed for data visualization such as scales, shapes, and layouts.) But what makes this any more useful than just looking at the Chrome DevTools accessibility tree yourself? Time Travel!
We wanted to extend Reactime’s time travel functionality for React state snapshots to our accessibility snapshots used to build our accessibility component visualization. And we did it! As the component map tab recorded a new snapshot upon any state change, so too is an accessibility snapshot recorded when a state change occurs.
We also wanted to give the developer a bit more information about each accessibility node, but wanted to avoid cluttering our tab’s UI. The answer? Tool tips! Tool tips include information like each node’s ignored status, its ARIA status, and its other attached relevant properties.
We also realized that a lot of developers might be unfamiliar with the particulars of accessibility and be confused about how to interpret our accessibility tree. So, we utilized Redux Toolkit’s modularized state management to conditionally render a legend describing the origin and important characteristics of their app’s accessibility tree.
And finally, while we’d like to admit that integrating the chrome.debugger API was a seamless experience, there was a drawback. By utilizing the chrome.debugger API, a distracting popup appeared at the top of the page whenever Reactime was spun up. The solution? As the popup cannot be disabled to prevent malicious behavior from extensions going unnoticed, we created an enable-disable button, which is also implemented using Redux Toolkit, reserved for our accessibility tab so the popup would only appear when specifically debugging for accessibility.
Additional fixes
In version 23.0, the clear button would only keep the most recently recorded React state snapshot, even if the user had jumped to a previous snapshot. This resulted in the Component Map tab displaying snapshot data relevant to the most recently recorded state, even if the current target app state appeared differently. So, we updated Reactime to make our clear button remove all snapshots except for the snapshot that reflects the current state of the user’s target app at the moment the button is clicked.
In conclusion
An already powerful debugging tool gets polished up and now enters the field of accessibility improvement, beyond the standard of remembering to include alt text. Our accessibility tab helps the developer navigate the intimidating challenges presented by accessibility issues that require more of a human eye.
If you’d like to contribute or play around with Reactime, check out our Github page!
Try the extension on the Chrome Web Store
Meet the v24 Reactime Team:
Jesse Guerrero| Github | LinkedIn
Visit our website and star us on GitHub!
In Plain English 🚀
Thank you for being a part of the In Plain English community! Before you go:
- Be sure to clap and follow the writer ️👏️️
- Follow us: X | LinkedIn | YouTube | Discord | Newsletter
- Visit our other platforms: Stackademic | CoFeed | Venture | Cubed
- More content at PlainEnglish.io
