Beginning The Accessibility Inspector's 3 Pane View
This week I began working on the next part of my internship project: embedding the Accessibility Inspector into the 3-pane view of the inspector panel. This part of my project will allow the inspection of a page with both the markup and accessibility tree views side-by-side. I am particularly excited about this part of my project since it would allow easier discovery of the Accessibility Inspector tool and it also provides better integration with more common developer tool use-cases such as inspecting the markup of the DOM tree. But before I started coding, I needed to create a mental map of how I wanted to solve this problem. I find creating mental maps of what I want to do is very helpful for sizeable tasks. This is usually an iterative process for me since I will try out what I planned, and if that doesn’t work, I either improve those plans or start new. Preferably the former.
The first question I ask myself is “what do I want to do?” For my project this is, like mentioned above, embedding the Accessibility Inspector into the 3-pane view of the inspector panel. When working on front-end features, I like to have a visual representation of what I want to achieve. In particular, I want to see the Accessibility Tree view shown in the middle panel and the properties view shown in the third:
It is important to note this screenshot, created in Balsamiq mockups, is only a high-level overview of what I want to achieve. From there, I ask myself “how am I going to do it?” This involves a number of tasks and are not done in any particular order:
- Examine how the Rules panel view (the middle pane) is done. I first examine the markup of this component using the inspector tool in developer tools.
- Read code. Where’s the component that shows these views? How are the tabs shown in the screenshot injected into a panel? I discovered the middle pane actually hides the tabs since it’s only the Rule view being shown.
- Try something out. I experimented with adding an “Accessibility” tab to the third panel. Right now if I can get a view component from the existing Accessibility panel showing, I should be able to show it anywhere.
At the moment, I believe I should be able to create my own “Accessibility” tab from this file:
devtools/client/inspector/inspector.js. This file contains the implementation of an Inspector component instance. The Inspector’s initializing method also calls a function called setupSidebar, which is where I should be able to create the tab I need. In
setupSidebar, a “sidebar” property is created on the Inspector by creating an instance of ToolSidebar. The “sidebar” is where we will be inserting the accessibility tab. In particular, “sidebar” has a method called queueTab which we can use to pass not only the label of our tab but also the view. Ideally, this would mean we can simply take the Accessibility Inspector’s React views and load it here.
This is where I am at in my experimentation with embedding the Accessibility Inspector. There are a couple of questions I discovered as I was playing around, such as how dependent were these views on certain services to be running. It turns out that for simplicity’s sake, it would be better to first have these services booted before the accessibility
views are injected into the panel. Therefore, the existing accessibility panel needs to be opened and have its services booted before navigating back to the inspector panel.
Goals for Next Week
I recently received feedback from a code review for the infobar component of my project. This next week I plan have all the suggestions and requests addressed. And, if I’m on a roll, even landed! I am also planning on having something actually showing in the 3-pane view for the Accessibility Inspector by the end of the week.