Recently Automattic hosted an online conference on design and exclusion. Instead of calling it a conference on inclusive design, they flipped the idea around to focus on what conscious and unconscious decisions lead to the systematic exclusion of people.

Inclusive design is about a lot more than the web and it’s about a lot more than accessibility. But, as web developers, accessibility – making sure that the HTML we generate can be used by everyone properly – is an important topic. So, I wanted to share four attitudes I think leads to us skipping over this important part of our jobs.

You’re Not An Accessibility Expert

I’m not an accessibility expert. But a fairly large part of my job is using PHP and JavaScript to put HTML on the screen and I think it’s an important thing to do it right. Just because I’m not qualified to do accessibility audits and I don’t know everything about accessibility is no excuse not to understand the basics of creating semantic and accessible HTML.

Like most web developers, I’ve spent a ton of time using the excellent Mozilla Developer Network site to learn JavaScript and look up how objects, functions, and APIs I don’t know work. They have an excellent section on accessibility. Also, the a11y project maintains a great resource on accessible web design.

You Don’t Want To Bill Your Clients For Accessibility

I know everyone’s clients are on a budget. But unless we’re talking about a project that requires WCAG certification, I’m not sure that accessibility is something you should charge for. I think it falls under “making the features work.”

If someone hires you to make a site or a feature for your site, budget the time for writing code that generates correct HTML. Don’t forget that writing proper HTML isn’t just about helping those using screen readers or other assistive devices.

Writing accessible code starts with following the proper semantics of the HTML language. Failing to do so hurts the effectiveness of other types of technology, such as web crawlers like those used by search engines.

On the same note, keep in mind that plentiful and affordable data is a privilege that not everyone can afford, literally. Some users may be turning off images to save on bandwidth, so the alt tag describing an image is for them, as much as it is for those with disabilities.

Staying with alt tags, a broken image link on a website is bad. But if the alt tag is there, at least I can tell what you meant to show me. It’s another example of how this basic accessibility feature leads to better functionality for all.

We Treat Accessibility As A Bonus

Architects spend a lot of time on accessibility because in most countries they are required by law to do so. It’s an extra expense to add a ramp in addition to stairs, but everyone does this because they have to. Laws like the Americans With Disabilities Act among other things require extra steps to be taken in order to make more inclusive designs when it comes to architecture.

The WordPress ecosystem has no such requirements, and we often treat accessibility as a feature or something you get with an add-on.

WordPress.org/themes hosts thousands of themes. Only 134 last time I checked were marked as accessible. If the WordPress open source project or ThemeForest had chosen to require a basic level of inclusive design for themes on the most popular CMS, how much more accessible would the web be today?

You Don’t Do Accessibility Testing

I know it’s hard to insist that people do something that they don’t know how to do. Personally, I’ve learned a ton by running the accessibility tester plugin. This plugin explains why my problems are problems and helps me learn how to avoid them in the future.

We test our sites on all kinds of devices to make sure that those using mobile phones or big screens can use our sites. But do we test with a screen reader? Do we test without a mouse? Do we test with data throttling on?

Your work will be more usable by everyone if you test for everyone. Using the WEBAIM checklist will lead to better sites.

It took Google adding an SEO penalty for nonmobile-friendly sites to get a lot of people to redesign for the reality of how much we use our phones for web browsing. It took Google penalizing sites that didn’t have SSL for people to start getting serious about encryption.

You Can Learn This

Look, I’m not perfect. My website needs work, but I’m happy that my plugin treats accessibility as a requirement, not a feature. I think everyone can get into that mindset of moving from thinking of what we tend to call “accessibility issues” and calling them what they are “bugs.”

One of the things that is great about WordPress is that we teach each other. I am aware of the importance of accessibility and inclusive design because of my involvement in the WordPress community. WordPress TV is a great place to learn about accessibility. Videos by Rachel Carden and Robert Jolly are a great place to start. The accessibility tag is also a great place to look. We’ve also written extensively on the topic here at Torque.

We can make the web a quantifiably better place if we make a change to our attitude on how we create HTML. I’ve seen the change from mobile-friendly as a bonus to being a de-facto requirement for basically all web development. It’s a change in attitude that can happen in terms of semantic and accessible HTML being a priority.

Josh is a WordPress developer and educator. He is Founder/ Lead Developer/ Space Astronaut Grade 3 for Caldera Labs, makers of awesome WordPress tools including Caldera Forms — a drag and drop, responsive WordPress form builder. He teaches WordPress development at Caldera Learn.

The post There’s No Excuse For Bad Site Accessibility appeared first on Torque.

Share This