Princeton University will host DrupalCamp New Jersey, from March 16 - 18, 2023. The Drop Times (TDT) has interviewed a few of the organizers and presenters for the camp, and the first in the series was with John Jameson. John is a Digital Accessibility Developer at Princeton.

TDT has been holding interviews with the presenters and organizers prior to various DrupalCamps. We have discussed their Drupal journey, careers, and the inspiration behind some of their passion projects. So far, everything has been quite enticing and educative. TDT reached out to John via Slack and conducted a written interview.

John started by working with a little bit of everything. "A vaguely defined job of a webmaster," he says, is how it all began. A generalist position took away the time required to learn any backend development. But then, having the opportunity to attend DrupalCon Chicago, he today works with all the things he didn't have the time for. And that is a lesson for every beginner doubtful about attending their first tech camp.

Follow through the interview below to read more about what John has focused on in his career and what he will focus on in his session at the upcoming DrupalCamp NJ.

TDT [1]: Can you give us a brief introduction about yourself and your work in Drupal? How did you first become acquainted with the community?

John Jameson: I suspect like a lot of people, Views was love at first sight.

Twelve or so years ago, I had one of those vaguely defined jobs that might be classified as "webmaster" or "IT person." It was a little of everything – CSS and simple JS, but also content editing, layout and desktop support. They had hired me as a photographer!

In a generalist position, I had no time to learn any backend development, but I was expected to manage Princeton University's main Web presence. The ability to push a few buttons, create a custom content type, push a few more and build a dashboard? It revolutionized what I was capable of building without bringing in a consultant. That first taste was at DrupalCon Chicago, where I had tagged along behind our central Web Development Services team. Fast forward to the present, and I am now on that team, as their "Digital Accessibility Developer"—specialized into all the things I used to not have time to learn.

TDT [2]: What does it mean to be a Digital Accessibility Developer? What are some of the projects at Princeton that you have overseen have taken the accessibility route?

John Jameson: Like all the best positions, it is something we invented to fit a need.

We were outsourcing website reviews to companies that would deliver highly detailed audits, but then, what comes next?

Princeton is a place with dozens of developers and several thousand people creating Web content. We had a robust training program, with dozens of CPACC (core accessibility concepts) certified staff, so we knew what to do with the straightforward content and design issues. But when a developer heard that their shiny new widget did not work in VoiceOver, they struggled to understand exactly what the problem was, let alone how best to fix it or how to confirm their change was actually an improvement.

So I specialized. I am now both an in-house accessibility tester and a "mentor-on-call." When I audit a site, I write up a detailed report explaining not only what things I found, but why things are issues and for whom, and how to fix it. That often leads to a meeting or two where I teach content editors how to structure what they write, or help the developers learn the ins and outs of ARIA and JS.

TDT [3]: You are a member of the Accessibility group on Drupal. What are some of the discussions and aims of the members in the Accessibility group?

John Jameson: The core members spend impressive amounts of time poring over issue queues, testing existing code and commits.

The rest of us mostly pitch in on Slack—discussing updates to documentation and Drupal coding standards, offering advice to module maintainers and developers who stop by for advice, things like that.

I think for most of us the goal is reducing friction. You do not want website users to be unable to read or operate the site, but you also do not want authors and developers to live in fear of doing anything without mastering some huge body of arcane knowledge. As much as possible you want the system and documentation to guide people towards using a template that has already been tested and is accessible out of the box.

One of the really challenging things about accessibility is that edge cases become very, very deep rabbit holes. There are key concepts we can teach quickly that cover most scenarios—things like making sure alt text describes what an image communicates to sighted users, in context, on a page, not what objects it contains.

But once you start getting into the weeds on complex interactive widgets, you run into situations where things that are helpful and useful for one group of people might be problematic for another. When someone runs into that, it's helpful to have a large group of experts pool their knowledge and iterate towards something that works well for everybody.

One of the other things we try to do is amplify the voices of disabled communities. It is common for new-to-the-field developers to think advances in AI are really close to solving accessibility barriers through overlays and automatic alt text, but what we often hear from blind users is that the current generation of these tools often make things worse.

You are not helping a screen reader user if your AI tool tells them an image is "a circle with lines," if it is actually "a pie chart showing that even the most optimistic marketing for automated accessibility checkers only claims to catch 57% of issues." And that meaning has to be provided by the author.

Learning how to build tools that actually help requires careful listening and testing. This is why I tend to focus my automation work on assisting the author in the first place, rather than trying to modify content on the fly.

TDT [4]: Some internet acronyms are funny. But we get the meaning easily. Someone new to something was once called a n00b. Later it turned awkward. Then internationalization and localization were written as i18n and l10n respectively. The currently popular acronym in accessibility is a11y. There are several groups that use that acronym in their name and even YouTube Channels. Are acronyms more accessible than the full name?

John Jameson: Like so many things, I think it depends on context.

Take "Editoria11y" for instance. Using an eleven in its name is terrible for accessibility in so, so many ways: Screen readers cannot pronounce it. Voice dictation users would have to spell it out letter by letter, to type it. The eleven looks a lot like lower-case L's, so developers are more likely to mess up their Composer and Drush commands. To people outside the field, "a11y" is just one more piece of weird insider jargon, and, depending on the font, is easily confused with "ally," which is usually associated with diversity/inclusion rather than disability. But: if you search the Web for "Editoria11y," you are going to get what you are looking for on the first hit. If I spelled it correctly, it would be buried. So I tend to default towards using jargon when working with people in my field, both for shorthand and SEO…but I will probably not be putting "l33t a11y h4x0r" on my business card. Probably.

TDT [5]: Your focus for your talk at DrupalCamp NJ is towards the Drupal-integrated Accessibility Checker. Can you explain the function of this tool, the milestones in its development and the benefits of it? Could you also brief us about the reason behind selecting this topic? What will the attendees take away from this session? Is there anything they must keep in mind prior to attending your session at DrupalCamp NJ?

John Jameson: When I entered the accessibility field, one of the first things I noticed was how much time I was spending teaching people the same basic skills, over and over. Entering the field with a dual background in development and in end-user support for content authors, I noticed that most of the mistakes people were making came from the tools encouraging errors. If you watch a content author make a heading—our authoring tools straight-up encourage them to pick a heading level aesthetically by size rather than structurally. If they insert a table, it inserts one with no header row by default. Users might not even know they can add a header—or even what a header is. The tools default to inaccessible content.

I also discovered that, across the board, the available checkers were either far too complicated for content authors, or depended on them to know to do something to check their work—be it pressing a button to start a check, installing a browser plugin or visiting a dashboard. Again, the default was towards inaccessible content.

I went somewhat nervously to my boss and laid out a spreadsheet I'd made of every mature tool I could find, from free and open source checkers to enterprise crawlers—roughly 30 of them—and showed her that there really was nothing out there that worked like spellcheck—something built into the CMS that would just automatically pop open and highlight content issues for content authors, without also overlaying a massive, terrifying interface full of design and code issues. The only person I could find even working on such a thing was Adam Chaboryk at Toronto Metropolitan University, who had put out there an early version of his Sa11y checker.

To my delight, she set aside a huge chunk of time for me to try to build something new. I forked Sa11y, converted it to run on-load rather than on-demand, and then spent months dealing with all the issues that presented: I had to make it much more lightweight and performant to not introduce jank on heavy pages, and I needed to make it smart enough to only automatically pop if it detected new issues, rather than on every page.

That was version 1, and it performed better than I could have hoped. The community response was ecstatic; I had people calling it "the best accessibility checker for Drupal" and one of their "absolute favorite Drupal modules."

As big a project as version 1 was, I was able to build it mostly out of things I was at least vaguely familiar with: jQuery and Drupal configuration.

The feature requests I received post-launch, though, all required skills that were going to be new to me: converting jQuery to vanilla JS, manipulating the shadow DOM, using the Drupal API to "phone home" results into custom database tables, and then using that data to build a site-wide issues dashboard.

For our local Drupal community: they have been along for the Editoria11y ride since the beginning, so it was this journey "under the hood" towards an interactive app-like-experience that was of interest to them.

So I am putting together something of a code travel-log of what it takes to throw an Editoria11y alert in v2, from running a test, to setting up an API route, to writing that API data back to the database, and then later retrieving it to build a site reporting dashboard.

This all sounds terribly technical, but the theme is, in a nutshell:

"grab some popcorn and observe that these are all modular building blocks Drupal or your browser provides, and each piece is not so scary by itself once you know what the moving parts do, so you shouldn't let imposter syndrome keep you from trying if you have some great idea."