I was reading something on Twitter a while ago. It started off as a kind of subtweet blasting some junky code written by a company who should know better. But the comment thread eventually evolved into a micro-conversation about design vs. semantics. The question was raised: why should code be able to style a paragraph to look like a headline? If it’s supposed to look like a headline, shouldn’t it be a headline? The response? “Because design has nothing to do with semantics.“
But does it?
Form vs. Function?
I would argue that an item’s function is directly related to how it looks. It’s how the eye interprets what’s happening on the page and makes the correct inference as to what to do next. If a piece of text is supposed to stand out because it’s important, then it should be written in such a way that it lends itself to being a headline, or at the very least, a sub-headline. This line of reasoning is directly in keeping with WordPress’ own accessibility handbook. So while I agree that CSS should be flexible, if you have well-prepared content, it doesn’t need to be.
Think of the visual representation of your content as a kind of quality assurance checklist for the user’s experience. Communication has a natural flow, a cadence, that doesn’t need to run counter to aesthetics and design. And while studies have shown that people will forgive a bad UI experience if the site is aesthetically pleasing (“I love the colors!”), it’s not too much to expect both from your website.
Greater Accessibility
One reason why content should act the way it looks is because it greatly increases accessibility for users with disabilities. This is something that’s frequently ignored in both semantics and design. Imagine trying to navigate down a page on your website while blindfolded. Colors don’t matter. Photos don’t matter (too much). What matters is the natural progression of information down the page. Using specific code solely for design purposes only accomplishes half the task. It’s a bit like displaying an image of a shoe, with an accessibility tag labeling it a hat. It might be close, but it’s not the same.
When most people think of “accessibility” in terms of websites, they usually think of accessibility for the blind. But a truly accessible internet also includes assistance for people who are hearing impaired, have motor impairments, or have difficulty with cognitive processes. Screen reading tools, for example, rely on specific cues in the code on a page to help determine which information is most important. People with motor impairments may have difficulty interacting with a website where buttons and other clickable items aren’t large enough to be easily clicked. And when it comes to cognitive issues, consistency in text display becomes even more important. Again, it’s extremely important that text is labelled to behave the way it looks like it should.
An Ongoing Conversation
Accessibility on the internet has been an ongoing talking point for years. The WordPress community works tirelessly to improve the platform and to establish appropriate usability guidelines for developers, designers, and content creators. With the most recent update to WordPress 5.0, which brought with it the introduction of the Gutenberg editing platform, the move toward greater accessibility is getting a boost of adrenaline. At the very least, Gutenberg’s considerable issues regarding accessibility have prompted some pretty extensive conversation on the matter. Experts in the field, including those who at one point worked on the development team for Gutenberg, have stated that Gutenberg is actually a less helpful editing tool than the classic editor. Why? Specifically because of the disconnect between semantics and design. This is a major problem which needs to be addressed, particularly since Gutenberg was just rolled out with WordPress 5.0 as the new default content editor.
Of particular interest to me was the recent discussion at this year’s WordCamp US regarding ARIA as an accessibility tool. As with many tools, there is a right way and a wrong way to use ARIA, and accessibility consultant Rian Rietveld gave a great presentation on how and why to use it.
Moving Forward
Other resources for those interested in a more accessible internet include:
- the A11y Project, which dispels a number of myths regarding accessibility while running a Github for contributors
- WPMU Dev, which provides a fairly comprehensive overview for developers on how to improve accessibility
- WordPress’ own initiative, Make WordPress Accessible, which includes a best-practices handbook and a support forum
There’s a certain art to the marriage of form and function. A fully-accessible website doesn’t have to look boring. Neither does a beautifully-designed website have to ignore proper content organization. It takes time and intention to create a digital experience that does both well, but it’s worth the effort.
