Putting Privilege into Practice

In this short series, I’ll be discussing the base concept of privilege – whether it is racial privilege, gender privilege, or even able-bodied privilege. It is not going to be an easy discussion, but try to keep an open mind.

Now that we have defined privilege and discussed applying it for good in theory, it’s time to put your privilege in practice in the websites you build and the content you write. It is time to talk about accessibility.

Able-Bodied Privilege

Being able-bodied is a privilege. A frighteningly overlooked one. The ability to read text on a screen is taken for granted. Touch screens have gone past the novelty of smartphones and tablets to a standard part of public life. But what about the people that can’t see a screen at all? What about the people who struggle to use a touch screen, or can’t at all? These basic abilities are taken for granted, and it is your job as a developer to stop doing that.

We’ll be focusing here on the low hanging fruit of accessibility. These are the issues that are incredibly easy to implement and make your site better with little to no effort. They will make your sites more accessible, but more importantly, help expand your mindset to give you a broader understanding of the forgotten public’s challenges.

Before we move forward with specifics, I do want to acknowledge that accessibility is a complex issue. Depending on where you live, legal requirements are vague, but that is changing. It may seem logical to just get the site or project done and fix the accessibility stuff when people complain or threaten to sue. In my experience and my clients’ experience, it is often far more expensive to go this route. Building an accessible site from the get-go isn’t just the right thing to do, it’s a smarter business decision.

Our definitions will be based on the WCAG 2.1 standards, the current working standards for web accessibility. Our goal is to meet A and AA level requirements, as those are what fall under most legal definitions of accessible websites.

Color Contrast

Have you ever wondered why so much print media, both physical and digital, is in black and white? Even when you have dark mode turned on, the message is clear – contrast makes things easier to read. The web gives us a variety of color options for print now. Black and white isn’t the default anymore, and that’s great, but we still need to make sure color contrast is factored in.

The minimum standard for color contrast is 4.5 to 1 (3 to 1 for larger text). This ratio is calculated by comparing the color values of the foreground and background – the black text on a white background, for example. Pure black text (#000) on a white background (#FFF) has a contrast ratio of 21, well above the standard. There are several color contrast checker tools available on the web. Just make sure you’re meeting the 4.5 to 1 ratio and you’re golden.

Resizable Text

If you remember the early days of smartphones, you probably remember pinching to zoom. You made the tiny text bigger so you could read it. Now phones and web browsers have text size settings that prevent the need for zooming. This may seem like a feature added for convenience, but it’s actually an accessibility improvement. The problem is far too often, your code will break that feature if you’re not careful.

Resizable text on the web is dependant on the CSS font-size definition of elements. When you explicitly define an element’s font size in pixels, you lock the size permanently. When you use relative units, whether they are ems, rems, or others like viewport width, the text can resize based on the browser setting. You can still set a default, as well as a fallback in the odd case that a browser doesn’t support relative units.

Semantic Markup & Content

When we talk about semantics, we’re not debating the meaning of words. In web development, semantics pertains to the meaning of HTML elements. A subtle difference, but one that has major impacts on how people and search engines see your website.

Organize your sites and content in a way that makes sense. Don’t use a particular heading because it easily sets the font size to be the way you want it. That should be done in CSS. More importantly, don’t build buttons out of a div element and then add their functionality with JavaScript. Use a button element or an anchor element (aka a link) depending on the context. Screen reader technology, the tech that helps visually impaired users “see” your site, depends on you doing so.

User-Generated Content

If you’re now worried about how you can prevent your client from making mistakes after you’ve handed off the website, good. You can do your best, but it’s not your job to police the semantics of a client’s content after they take over the site. The new Block Editor for WordPress theoretically makes this scenario worse because clients have even more freedom and the ease to make these big mistakes. Fortunately, the developers of WordPress thought ahead.

The Content Structure panel inside the Block Editor, indicated by the “i” icon, tells the user when their content is misaligned structurally. It analyzes the blocks in use and builds a semantic chart of headings. If one is off, it notifies you.

Tip of the Iceberg

As I said, accessibility is a complex issue. The code is often easy, but there are a lot of different factors, and explaining each one is well beyond the scope of this discussion. I’ll be digging into them soon. The key matter is that you take care of some of these simple, low-hanging fruit. Handle them and the websites you build will be far less privileged.

See Me In Miami

Thanks for going on this brief journey of privilege with me. I’ll be discussing this topic soon at WordCamp Miami 2020. I’d love to see you there so we can discuss things more in person. Tickets are still available but are going fast.

I’ll update this section with the talk video once it is available. Hope to see you there!

Photo by Judita Tamošiūnaitė from Pexels