TL;DR
This article introduces the ideas that:
- Digital writers are active designers of HTML content.
- Unintentionally ableist writing and design creates ableist products that miss market opportunities.
- The digital paradigm needs care in design, writing, and orienting everyone.
- HTML presentation is important to reading regardless of ability.
Institutionalized Ableism
Our readers vary by anthropological (belief, experience, motivation, environment, learning styles and preferences, etc.) and physiological attributes. There is no normal.
The myth of ‘normal’ is perpetuated within cohorts of ‘normal’ people: how far ‘normal’ will slide left and right of center depends on each cohort. Generally, ‘normal’ are ‘fully able’. We then design and manufacture to the ‘norm’ and treat anyone outside our ‘normal’ personas’ parameters as edge cases.
- Emergent Thinking: About Face is a reference book for many interaction and UX designers. It mentions ‘accessible personas’ on page 400. It’s 2021. Let’s move the agenda to page 1?
- Habit: When UX and UI designers hand-off static wireframes of fixed-scale desktop webpages, developers tend to build to them. Without design, the accessible and inclusive strategies required by law and lore tend to be absent.
The common most definition of ‘normal’ is able. People with less than ‘normal’ ability are labelled ‘disabled’. As ‘disabled’ are a minority, and as ‘normal’ cohorts of ‘able’ people do not experience products from a ‘disabled’ perspective, we are likely to design for ‘normal’ people by priority. Non-normal people are treated separately. This is ableist and of course breaks our enterprise’s inclusive policies.
Scenarios
Edge cases are not personas. They are scenarios.
Scenarios can apply to anyone temporarily or permanently. As an extreme example, you may lose or injure an arm or have it temporarily disabled by your environment: carrying something, etc.
Scenarios also apply to changing circumstances so in the same way, you may have a visual deficit and require high contrasts to perceive writing on a screen or have ‘normal’ vision and work on a screen in direct sunlight, needing an adjustment to the screen’s output. You may also have poor connectivity, be distracted by life stressors, or simply not motivated to work through an online solution.
Accessibility
Accessible is not inclusive. We may access content and not use or comprehend it. Consider a link written, “Here“.
Visual, mouse, keyboard, touch, and non-visual users can access the link. Only those who can see it in context will understand what it links to. When you understand a link to be a transaction or contract, then you have an idea why, ‘here’ may be too vague to commit to?
- Does the link point to what you want or need?
- How do you return to where you leave the current document?
- Will it open an HTML, PDF, or image document?
- How much data or time resource will opening or downloading it take?
Explainer
Screen reader users may navigate through your document by links alone. ‘Here’ describes nothing of interest and is useless without the surrounding context. Two ‘Here’ links make each redundant – regardless of destination, the links are the same and cancel one another out from being useful (accessible). Both are only here.
Automated accessibility checkers look for programmatic barriers to use. That’s it. They do not (yet!) understand the nuances of inclusiveness or individual scenarios that affect usability, usefulness, or learning. The ‘Here’ link is perfectly encoded and there is only one on the page. It’s 100% accessible and compliant.
The rub
Most on-screen content is likely to be ‘accessible’ without applying any skill. Dog poo is accessible, too. You don’t want to wade through it.
Pat Godfrey – Dog Poop is Accessible Too
Inclusive
Inclusive, or sometimes labelled ‘universal’ design includes our writing. When we present our content as HTML then we can make it accessible and better, we can give everyone an inclusive experience.
There is a great deal we can do already to ensure our writing is inclusive from use of language, vocabulary, ‘reading age’, information architecture, pace, structure, etc.
In our current roles, much of the HTML presentation is taken care of by others. We must trust that they present our editorial intent as inclusively as we have worked to write it.
Linear vs. Dipping In
Digital and indeed any reference content is not read from beginning line one to end of last line. We tend to dip in and scan through it.
We can help our readers orient to our content and its architecture using patterns such as headings, paragraphs, lists, and section breaks and even new pages.
The design of how we orient our readers to our content is arguably as important as the content itself. For example, our training may be ‘beginning, middle, and end’ whereas our busy web page reader will want the summary delivered first and the evidence after. “What must I do?” before, “How must I do it”. (Pyramid writing).
The key reflection here is to manage expectancy. When our reader arrives on a content-heavy and long page, they may not feel too positive about it. Explaining (summarizing) and signposting the content and breaking it down into manageable chunks usually helps. This includes paragraph structure, headings, and extracting ideas from paragraphs and laying them out one item at a time in a list.
The visual patterns of copy text on a page add to the content’s attractiveness and context. Lists and paragraphs, headings and tables present visible and semantic content patterns that help lead readers through their learning and an express information to preferences.
Cross-Page Navigation
We can string chunks of content across pages in the hope the reduced visible volume of writing reduces anxiety.
In testing, you may find distributing a topic across pages is less usable and more difficult to refer to than a long page through which our reader can scroll. In-page navigation can be far more easily understood and used in conjunction with scrolling and Back to Top links than cross-page navigation. It’s not a book we can flip through. It’s a document we can navigate.
HTML as a Medium
As digital technical writers and regardless of input method, our output medium is HTML. React, Angular, iOS apps, PDF; their end presentation is HTML tags and attributes.
HTML is a simple and (mostly) accessible code written as an interface between we the content producers and our readers’ browsers. It’s imperfect and made less perfect still by poor or lazy use.
We can learn HTML quite easily. 16 tags are more than enough to speed you on to writing a web page. The priority is to understand semantic vs. non-semantic tags.
Semantic and Non-semantic HTML
A semantic tag reflects or perhaps better, describes the intention of its content. For example an image (img), paragraph (p), or heading level 3 (h3). More complicated components like forms, tables, and figures are built from a set sequence of semantic tags. A browser knows and can communicate semantic tag contents to our readers visually and non-visually.
Non-semantic tags are those used to define space within a document. The worst of them – and perhaps most useful are divisions (div) and spans (span). Developers habitually misuse these in lines of code referred to as, Div and Span Soup (barf!).
They are empty containers. They have no definition attached to what content they contain unless the content is formed of semantic tags.
Divs are block elements: they want to take up a whole line across their parent container. Spans are in-line and only as ‘long’ as their content. Spans can be made block using style attributes defined in Cascading Style Sheets.
CSS
CSS is a complimentary code to HTML. It enables us to separate content (HTML) from presentation (CSS) caveat semantic HTML tags each have a default presentation all of their own and programmed into each browser. As each browser is differentiated by their vendors, the default presentation is often different.
The default presentation is often thought of as ugly. It’s probably as close as we can get to a typed paper manuscript with one important difference; it automatically adapts to the page width and is reasonably visually accessible. We can also zoom in to it and update its default appearance with CSS.
CSS is powerful and can add visual barriers to HTML’s presentation and render it completely inaccessible. We can over-ride CSS in our browsers so it should be considered transitory.
As CSS is a form of labeling and identifying content, it is often used to anchor and target JavaScript functions:
- Class. These enable one or more elements to be grouped within a class.
- Identity (id). Think Highlander! There can only be one id used in a document.
In this way, a visual style or JavaScript function can be applied to a unique instance identity, or to many instances of a single class.
JavaScript
What flavor? There are so many! Vanilla or raw JavaScript is quite a complex language made easier to apply using libraries of pre-written JavaScript functions. JavaScript can update content, HTML, CSS, attributes, and almost anything else within a document.
Buttons must have JavaScript enabled to function usefully. They need programming with exception some form buttons that our browsers know how to handle by default (form Submit, Refresh, and Cancel).
Mantra:
- HTML = content.
- JavaScript = Function.
- CSS = visual presentation.
Basics of Accessibility
The very basics of accessible HTML writing have the most extreme and positive effects. They convert visual strategies to inclusive ones and often focus on blind readers using screen readers (or Braille displays). They include:
- Use of regions. These are announced to screen reader users who rely on these regions to orient them to where in a visual-biased presentation they are, or need to be.
- Links. Links are what the Interweb is all about – stuff these up and you are perceived web-incompetent.
- Headings. A semantic heading structure assists all readers to follow our content. Screen reader users may navigate content using headings surfaced in lists by their browser technologies.
- Lists. Unordered and ordered list help to inform screen-reader users on how much content will follow. A visual user will scan and see five items: a screen reader user will not and needs informed audibly when a list starts and in some circumstances, how many list items there are to read.
- Tables. Correct use of columns and rows to describe data.
- Images. To alt or not to alt, that is the question!
- Show and Hide. When panels display or are hidden and how we inform particularly screen reader users when the user interface has been updated. An example is the DP TOC.
When we open a page in a browser we can examine the HTML that forms it. When the basics of semantic HTML and accessibility fail and given that they are so easy to achieve, then confidence in the digital product is eroded. When a team cannot get even these basics right, then how can they be trusted to get the complicated stuff done well?
Back to Why?
Visual browsers display web content according to the HTML, CSS, and JavaScript used to program them. This is generally designed by visual designers who may introduce visual and non-visual barriers without knowing to.
Disability
Many people who use the web have one level or more of ability that ‘normal’ designer cohorts may consider a disability. As a rule of thumb, at any one time near 20% of adults have a disability that may affect their use of their computing device permanently or temporarily.
Disability is not a constant. It is a sliding range of physical, cognitive, and environmental factors that may limit access to web content. Age, disease, injury, and parenthood (including of puppies) may diminish ability, too.
At one time or another, we will all be or become less able than we believe ‘normal’ ability to be.
‘Disabled’ Readers
Our readers may be disabled by their environment, physiology, psychology, prior experience, learning styles and preferences, and… and… and forever a list of potential barriers to reading and understanding what we write.
As inclusive writers, we can design our writing to be as inclusive as possible. We trust our CMS to be equally as inclusive from its visual design to its HTML, CSS, and JavaScript functions.
“But our readers are developers and must be ‘normal’ like us”!?
No. At the most extreme, our customer developers may be totally blind, or more likely have color perception differences, or learn differently to you, or read English as a second or third language, or be sat on the loo catching up on our content using a mobile device.
Why do we fail to notice these things?
Reflect on your development as a writer. Is there any time you have written for blind people using the Interweb? Or, have you been educated and groomed to write within an ableist society for ‘normal’ people believed to be the most lucrative customer?
In the US alone, according to a study c2016, billions of dollars of eCommerce were lost to inaccessible websites. Billions. Why did we not notice? Again, because our marketing and monitoring systems are ableist by design. We can’t see the failure when we measure only success.
“There was an uplift in conversions of 15% when we shifted the CTA from left to right.” How many more sales would only labeling the button inclusively have converted? Fix it later and it is too late. The site is marked as inaccessible and those unknown numbers are long gone.
Summary
Without an inclusive design approach to our writing and its presentation we will create barriers that occlude some workers from performing their duties. Many of these people are already and daily surmounting incredible challenges to exercise their gifts and talents. Who are we to deny their opportunities with our products?
Everyone banks. Anyone can develop code or run a business. Opportunity lies outside ableist practices.
Accessibility and inclusive design are doing the right thing. Like race and religion, people are born to or adopt subconscious bias and discrimination. In our mainly visual discipline, our learned ableism diminishes our standing as an inclusive enterprise.
We can and should demand that our content’s presentation is inclusive and must first ensure our content is.