Reflecting on Accessibility at MagnoliaJS 2023

Several weeks ago, I attended the annual MagnoliaJS conference that takes place around my neck of the woods, Jackson, Mississippi. I’ve had a lot of thoughts circling in my brain since then, and now that the year is winding down, I’ve had some time to reflect a bit more and put them into words.

I was there in part to cheer on my brother, Blake Watson, who presented on “The joys of home-cooked apps.” He is a prolific creator of random side projects, which I aspire to be some day.

But, the most popular topic of discussion by far was web accessibility, also known by its numeronym — “a11y.” While accessibility has been a hot topic for several years now, I feel like I’m only just now beginning to wrap my head around best practices.

Over the last couple of years we’ve been working on ramping up our accessibility services here at Storyware. This conference, therefore, helped me put some things into perspective as I continue to improve my awareness of common accessibility issues.

With that in mind, here are some things I learned about accessibility at Magnolia JS.

Do not use an overlay plugin

Here’s a really practical piece of advice maybe everyone knows now but I didn’t: Overlay plugins have fallen from grace.

These are paid services that provide third-party scripts for you to place on each page of your site in order to display an accessibility panel that hovers in the bottom corner of your site with controls for increasing color contrast, making fonts bigger, and many other features.

In Chris DeMars’ presentation “Accessibility in the Enterprise: The Relationship of A11y and ROI,” he briefly but emphatically recommended against these.

I asked Chris and some others about overlay plugins, and it turns out that while they were popular for a brief period a few years back, they just don’t stand up to rigorous testing.

And that makes sense. The WCAG standards for web accessibility are written for developers to implement on their own code, not for invasive third-party scripts. Even if overlay plugins did help, there is no reason in 2023 not to code with WCAG in mind. Not only can it make your website more compliant to applicable laws but it also makes it better for everyone.

As Chris said in his talk, everyone is disabled at some point in their lives, even if only temporarily. And more times than not, having appropriate color contrast, functional navigation and the like makes your website more enjoyable even by people who aren’t disabled.

Focus is important

Karl Groves, in his talk “Everything you need to know about JavaScript Accessibility in 40 minutes,” gave some key insights from his work on healthcare.gov and other websites.

Specifically, he implemented a login modal in vanilla JavaScript. We’ve all seen modals (also called “popups”). The purpose of a modal is to take the user down a different journey and allowing them either to continue down that journey or to return back to the path they were on previously.

With this proper understanding of the design pattern called “modalism,” it soon became clear just how many accessibility issues this can cause when not programmed properly.

Visual users, such as myself, can easily see the pattern: I click on “Log in,” a modal appears, and I can either log in or click “X” to close the modal and return my gaze back to whatever I was viewing beforehand.

But if I attempt the same interaction with a screen reader, such as macOS’s VoiceOver, the modal pattern can easily break down. For instance, if I click “Log in,” the modal may appear visually, but if the code for the modal is simply appended to the DOM, VoiceOver will still need to read the rest of the page before arriving at the login form.

Karl pointed out that you can go a long way by simply managing focus with JavaScript’s Element.focus method. By calling focus on the modal’s login form inputs, for example, we can prevent the screen reader from having to read the rest of the page first.

“Compliance” is complicated

Chris DeMars also pointed out that while there are many industry standards, especially WCAG, legal compliance is a moving target.

For example, in the US, the Americans with Disabilities Act requires websites to be accessible, but the official ADA website points out that “[t]he Department of Justice does not have a regulation setting out detailed standards.”

Various services may overpromise on “ADA compliance,” when in reality compliance is assessed on a case-by-case basis when lawsuits arise. Often, agreements can be reached to allow a business to reach compliance on a set timetable with possibilities to request extensions as needed.

No one can promise you that you won’t get hit with a lawsuit. However, the more accessible your site is, the less likely you will face legal challenges. Furthermore, it doesn’t hurt to be able to show that you took steps to implement industry standards for accessibility.

Avoid shooting in the dark

Often as a developer, I feel like I’m shooting in the dark when implementing accessibility requirements.

For standard website use cases, I can test in my browser and get that magical feeling all developers get by clicking reload and seeing their changes take effect. With modern browsers’ extensive dev tools, I can test for mobile, tablet, slow networks, and other scenarios.

But testing screen reader use cases, for example, hasn’t been as easy. Instead of being able to experience how people with vision impairments actually use my site, I’m usually left frantically adding alt tags and running automated color contrast tests and just hoping for the best.

As mentioned earlier, Karl Groves used the free screen reader that comes with macOS, VoiceOver, to test his example login modal.

I was really impressed with this, because it could open up opportunities to go above and beyond just meeting basic requirements. I hope to use tools like VoiceOver more in the future so I can really get a sense of what it’s like for the end user. Not all use cases can be manually tested, but it will be nice to have more options.

Avoiding deceptive patterns

Last but not least, Todd Libby, a W3C Invited Expert, closed out the two-day-long conference with an interesting and passionate talk on “deceptive patterns.” Todd works on W3C’s FAST document, which advises creators of technical specifications and compiles an inventory of functional and user needs.

A deceptive pattern is a user experience that has been intentionally designed to take the user down a path that they did not intend. An example is hiding the ability to cancel a subscription in the fine print or forcing the user to take tedious steps to discontinue a service (the “roach motel” pattern).

Other examples include:

• Unsubscribe shaming – email unsubscribe notifications that are intended to guilt you into resubscribing by using overly dramatic messaging.
• Comparison prevention – hiding lower tier pricing from the main pricing page.
• Trick questions – tricking people to opt in for email lists by using ambiguous language or complicated checkboxes.

While deceptive patterns are important for developers and designers to know about in order to avoid, everyone who browses the internet, especially if they are spending money, can benefit from recognizing a deceptive pattern when they see it. Todd pointed out that in his testing, many people were negatively impacted by these patterns.

In addition to accessibility talks and other interesting topics, MagnoliaJS was just fun in general, with a hilarious emcee, good Southern food, and ridiculous Halloween costumes. This was my first time to attend in person, and I hope to return next year.