The uncanny valley of a user interface: repeatedly, inevitably, stupidly doing a task wrong and not knowing if it’s your inability to learn the goddamn thing or if you’re a victim of appalling UI decisions by the product designer.
When building frontend stuff, a common challenge is finding responsible ways to hide content without alienating any audience segment.
There are a series of scenarios that need to be considered:
Most of these can be solved with CSS, although not without some hacks. ARIA can also help. Naturally, this conversation revolves around accessibility best practices.
I’ve compiled six techniques — with code examples, comments and references — on an accessible hidden content tests page.
They’re not complicated examples, and I have tested them on iOS, Mac OSX 10.6, and NVDA on Windows. I have tried multiple times to install WindowEyes for further testing, but it simply will not work on either of my PCs. If anyone wants to volunteer their testing abilities, I’d be obliged.
Actually, I’ll take any feedback. This can be a solid reference for all developers if vetted properly.
You, the designer, are Achilles, hero of the Trojan War, star of the Iliad, and overall mythological stud muffin.
Your client is a tortoise.
Also, your client has a new project. When the project starts, they have a preconceived vision of the end result. Despite their tortoisey speed, this is a head-start. You, the designer, slayer of Hector and legend even in his own time, reads the creative brief and leaps to catch up by executing on your vision of the project.
Somewhere there’s a finish line where your visions align.
But does the designer ever catch the client?
Zeno of Elea was a philosopher and contemporary of guys like Plato and Socrates. He’s best remembered for a set of mathematical paradoxes (known as Zeno’s Paradoxes) that were written to challenge the thinking of the day.
The “Achilles and the tortoise paradox” posits that in a race where the tortoise has a head-start, Achilles will never be able to catch up because during the time it takes him to reach a given position, the tortoise has moved forward again.
Of course, you know that Achilles will pass the tortoise without troubling our brain to math all over itself. But the paradox still forces you to pause, dance your fingers in mimicry of two bodies in motion, mumble thoughtfully, glance suspiciously at a turtle, and ultimately shake your head in bewilderment. We can theorize that Zeno excelled at annoying his fellow togas.
With equal confidence, you know that you will catch up to your client and deliver their vision. But during the fervor of the race, when the client keeps shifting positions and you keep scrambling and the finish line isn’t even a blur on the horizon, paradoxes become the normal.
Almost any information-oriented web page is dependent upon a core, central block of content. Because content is entered via a single large textarea in the CMS, this “central block” has two looming problems:
Blobs and crap. Not the best way to start a day.
Recently, Rick Yagodich (@think_info) articulated and illustrated an approach called “WYSISMUC” to solve this challenge. This post is a riff on his post.
WYSISMUC (“what you see is structurally marked up content” or “whizzysmuck” I guess) is a concept that might help lead us out of this bog of unstructured stench. From Rick’s post:
In truth, there is a simple way to … allow those writing the material itself to work in a pseudo-WYSIWYG way, while maintaining a solid semantic structure underneath. After all, if you can take highly structured, chunked content and transform it for presentation as a single semantic block, why not reverse engineer the process?
The basic premise:
Inside a CMS, an author’s interface would have the standard textarea for that “central block” content input, but instead of an Old Country Buffet of formatting icons, a highly confined set of choices to enable basic structure. (Think interfaces like BaseCamp, Drupal 8, or Medium.)
More importantly, a second set of controls would enable rich, structured data to be applied by selecting blocks of text and clicking a key button — a pattern not unlike filling out fields for an anchor tag. Rick’s post cited a person’s bio as an example, and I’ll build off that:
What if we could do the same with a business, or, in this case, an event?
Any website could use these general examples. It’s even more fun to dream up structured components relevant to the subject of the website:
(Further rabbit-hole thinking: imagine the same concept applied through the magic of external APIs. Instead of adding all of your own albums and artists, why not pull data directly from a source like discogs.com?)
The WYSISMUC interface promotes two important things: content structure and content relationships.
First, the modular, structured data provides the raw material for producing smart HTML. Think about the effort for marking up an address using a microdata schema …
National Audubon Society, Inc
1200 18th Street NW Suite 500 Washington, DC 20036 United States
Phone: +1 202-861-2242
Fax: +1 202-861-4290
audubon.org
This detailed markup converts human information (a place) into machine information that can be indexed (an organization, their map-able location, and associated contact information). This is a critical translative layer for things like Google Maps or recipe searches. See also RDFa and microformats.
To ask authors to produce this level of markup by hand would invite bloody mutiny. But when we capture structured sets of data right from the core author experience, implementing a dollop of template logic to dynamically produce the above block would be trivial.
More importantly, we’re creating relationships within the CMS itself. This is the magic. Islands of content inside a CMS are as useless as unmanaged HTML files on a server, so building programmatic ties creates a neural network that blows open Cirque du Soleil-like possibilities of content use — hopefully driving toward a richer, more customized, more engaging user experience.
Some examples off the top of my head:
And these are all ideas just on the website. We’ve not even scratched the surface of publishing to channels like email and social. Just thinking about the possibilities of content remixing, re-use, recoflabulation is enough to get me drawing boxes and lines for days.
Traditional database-driven CMSs will have separate screens for different kinds of data: one screen to add a new author, another screen to enter a new blog post, another screen to manage events. Anyone who manages content on a site understands the tedious activity of traversing back and forth between these screens.
WYSISMUC eliminates much of that by exposing relevant schemas in the writing context. Workflow headaches are reduced, and ancillary datasets grow organically.
Structured content gives code-wranglers hooks to collect, parse and re-assemble the information in a web page. Access to smarter data encourages smarter layouts, and removes clunky workarounds like regex pattern matching.
Governance is both simplified and complicated. There’s the training speed bump, of course, and then enforcement of WYSISMUC best practices — making sure the right stuff is captured. The big upside is the mitigation of blobitis, and giving meaning to discreet elements. This also enables product and page designers to better articulate user experiences when they know exactly what kind of data is available.
There has been some thinking on this previously. The SemTag prototype was an effort to select text and apply richer tagging. Certain content management systems like SDL Tridion have “component” linking that approximates some of the functionality without much elegance. The WYSIWYM community has talked about the importance of structured content over candy-coated visual presentation for years.
Rick’s post extended the idea to non-standard formatting objects, which is critically important. We’re moving the interface away from a strict “one-button-per-HTML-tag” model to a hybrid of essential HTML controls and a set of “one-button-per-relationship”.
Content and accessibility are not independent, parallel strategies. They intersect so early, and criss-cross so often, that their relationship could be classified as symbiotic. Accessibility cannot happen without good content, and an accessibility-conscious writer is automatically equipped to write better content. What is good for the flower is good for the bee.
WCAG 2.0 touches the codependency of accessibility and content in Guideline 3.1, “Readable: Make text content readable and understandable.” The specific recommendations are development-oriented, focused more on language accessibility than content meaning. That’s OK, because the mechanical stuff is what enables assistive devices to be, well, assistive. Points like defining the default language, defining abbreviations and providing a glossary can be specifically measured and graded. They support the letter of the law.
But Guideline 3.1 loses the spirit of the law. Again, the title is “Readable: Make text content readable and understandable.” — but there are no guidelines on tone or voice, just technical nods to reading level and a nudge to reduce jargon. This is like teaching someone to drive by spending the entire lesson on how to read a map.
Contrast this with Guideline 14 of WCAG 1.0, the since-replaced recommendation from 1999:
Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.
Guideline 14 — “Ensure that documents are clear and simple” — was marked as Priority 1 in WCAG 1.0, which makes its absence from WCAG 2.0 even more mystifying1.
Here’s where an organized content strategy can support a conscientious accessibility strategy.
In many organizations, the writing or brand team maintains a document describing tone, voice, and overall writing style. Sometimes it governs just a website, sometimes the entire company. To support accessibility, this document should encourage writers to use natural, straightforward, jargon-free language. Where WCAG 2.0 fails, your team can make the difference.
Here is an example from a style guide we recently published:
Though our topics can be complex in nature, how we communicate the message should be clear, direct and conversational. Make word choices that are plain-spoken, not meaningless jargon, and when a shorter phrase works, use it.
Elsewhere in the guide:
Copy and content should always be relevant to the reader, knowledgeable about what specifically ails them … This means using familiar language/terminology and examples that speak to the unique needs/pain points of that audience.
Our style guide never calls out accessibility explicitly, much less discusses WCAG guidelines. It doesn’t need to. Writing teams are encouraged by their managers and functional editors to focus on creating content unpolluted from balderdash, banality and bullshit. This is enough for our team. More explicit direction and justification may be needed for yours, and if so, the following bits might help justify the direction.
Obviously the marketing benefits of clarity are, um, clear.
From an accessibility standpoint, writing sans hackneyed argot helps address three core issues:
There are two kinds of cognitive disabilities: clinical and functional2. Where numbers for physical disabilities like vision, dexterity and hearing are well-published, the cognitive side is harder to pin down, starting with the very definition, which loosely includes ADD, dyslexia, reasoning deficits, memory loss, and more.
Most experts agree this group is the largest of all types of disabled folks. Unfortunately, it is also the least researched and most poorly represented by the W3C because not many mechanics of web development can be uniquely applied to helping the mentally challenged.
The challenges of the cognitively disabled in reading your content are nearly identical to people whose first language is not English3.
Finally, machine interpretation (screen-reading and voiceover technology, automatic translation and captioning) does not necessarily require simple language to function, but the human on the receiving end is going to be able to process and retain “red” better than “garnet”, “long journey” over “protracted peregrination”, “our product is great” over “imagine the prodigious theatre of life-changery unfolding even as you attenuate to its scintillating grandeur”.
You laugh, until you see real-life examples.
1 This deficit in WCAG 2.0 was recognized at the time. There was a formal objection issued in 2006.
2 The differences in clinical and functional cognitive disabilities are well-covered by WebAIM.
3 Replace “English” with your website’s primary language of course.