“Attention Deficit Hyperactivity Disorder.” I was 35 when the Psychiatrist confirmed it.
I felt conflicted. I’d spent years in counselling trying to figure out the inside of my own head. I thought I had a pretty good understanding of who I was. Now, I doubted if I knew myself at all.
I knew I had quirks. Looking at them now, some of them are textbook ADHD traits. But I also struggle a lot with Impostor Syndrome, Anxiety and Depression. This obviously made my ADHD difficult to diagnose because a lot of the traits can also be attributed to these comorbid conditions.
Because of this, ADHD was not something I’d ever really considered. It was actually my partner, Eliza, who first suggested that’s what it could be.
I guess, like most of society, I had a preconceived idea of what ADHD looked like; and it wasn’t particularly positive.
It’s now 2022, and I’m still seeing far too many websites using static pixel sizes for fonts. Even big hitters like Facebook do this.
Using the wrong units of measurement in your Cascading Style Sheets (CSS) is a big barrier for many visually impaired users, and it can cause your website fail the Web Content Accessibility Guidelines (WCAG) 2.1 on 1.4.4 Resize text.
My initial thoughts were to decouple PA11Y from it’s headless browser, and run it as part of the Selenium tests, rather than booting up 2 separate browser instances which would add seconds onto each test they could just both hit the same page when it was open.
However, on closer inspection, it turns out that using both is actually far simpler than I anticipated. PA11Y has the ability to use different ‘runners’ or plugins. So, using axe-core and PA11Y together is as simple as passing in the runners in as an option.
We use axe-core by Deque regularly as part of acceptance tests. With GitLab now offering PA11Y as part of the Continuous Integration (CI) Pipeline with zero config, I wanted to understand how it stacked up against axe-core. Can you drop axe-core for PA11Y? Can you drop PA11Y for axe-core? Should you use both?
5 arguments against accessibility and why they are wrong
In my role, I deal with many different teams and organisations. I also get involved in a bunch of other things on the side, just because accessibility is so misunderstood. One thing which has become quite apparent is that there are some common misconceptions regardless of which team, department or arms-length body you talk to.
I’ve pulled out 5 of the most common arguments I hear for why people think they should be exempt from doing accessibility work.
It’s not citizen facing, only our staff will use it
We don’t have any users who use assistive technology
The supplier plans to make it accessible at some point
Accessibility isn’t a priority right now, we’re working on other features first
Accessibility wasn’t part of the original cost, so we need to claim disproportionate burden
I remember in school we learned about the fire-triangle. Fuel, Oxygen and heat are required to make a fire burn. If you remove any of those things from the equation, the fire will use up what it has left and eventually burn out.
We can think of accessibility in a large organisation in the same way. There are 3 core parts. Compliance, education, and culture. If you lack any of these 3 things over a sustained period of time, the strategy is unsustainable and your ability to consistently deliver accessible services will burn out.
As an interaction designer, I hear a sentence at least once on every project I work on. “We can’t do that because [insert mediocre excuse here].”
A lot of the time this is because of technology restrictions. We can’t integrate with legacy systems. Or, we can, but the legacy system wants the information in a ridiculous format. So we have to change the design to ask for a mandatory middle name, where people have to write “none” in the box to progress. Urgh.
It’s easy to make a snap decision, bow to peer pressure and change the design. After all, we don’t want to waste our time designing something that’s not possible.