We should stop writing the “and/or” conjunction. Its visual meaning is ambiguous and the audible experience is horrible when announced as, “and slash or”. We can design an improved experience when we write inclusively and using the right codes.
The HTML forward slash is a visual math “division” operator. Its audible experience is, “slash”. When our writing habit is to conjoin “and/or”, we generally intend it to mean one of the following, but which?
- “and, or”
- “either or both”
It’s also used as a data divider. We use it within:
- Performance scores (7/10)
- Web addresses (https://blog.learningtoo.eu)
- Dates (02/02/2022)
Decoding this ambiguity audibly and even visually adds to our cognitive load. It’s worse when the symbol is used without context.// (For your information, that double “slash” is an old radio ham slang for a new paragraph, correctly typed as “=” or “BT”).
The “and/or” conjunction is rejected by law, too.
Is it a word? Is it a phrase? American and British courts have held that and/or is not part of the English language. The Illinois Appellate Court called it a “freakish fad” and an “accuracy-destroying symbol.”
Writing “and/or” is grammatically correct and there is debate on its use. For example in, Grammarbook’s article, What About and/or? The missing piece in the debate is how the slash affects our digital reading experience, especially for people using screen readers. In our audible experience, the symbol is announced, “SLASH!”
You see, and you probably do, there’s a difference between integrating people (accessibility) and including people (inclusivity).
“There is a substantial difference between integration and inclusion. Integration is the process of making a person adapt to or fit into society, while inclusion refers to the process of changing society to include everyone, regardless of their impairment status”.
From Disability-Inclusive-Language-Guidelines.pdf (UN GENEVA).
Our aim should be to include all people within our business. “Slash” may be accessible because screen reader users can understand it has a meaning. But, is it inclusive, especially when the symbol isn’t semantically correct or used consistently?
People may find converting the forward slash into our intended semantic difficult. Is it “either”, or “either, or both”, or “and”, or even “or”. People affected may be those:
- With less-developed reading skills
- With reduced cognitive ability
- Using assistive browsing technologies (ABT) such as screen and Braille readers
- Artificial intelligence when predicting, inputting, or outputting the meaning of a “slash”
The cognitive effort taken to visually read and convert the meaning can challenge visual readers. People using audible ABT may experience greater effort re-scanning for exact context of what they hear as, “slash”. Whichever, the finite semiotic is open to misadventure.
There is a good reason to omit the “and/or” conjunction from legal or instructional documentation.
Non-gramatical usage and standards
The “slash” is used between a performance score and score available, for example 7/10. It’s written to format a date like 02/02/2022, too. It’s also used as a division or divider when not intended to divide. You get the idea.
The forward “slash” is the (visual) math operator for “divide”. This is despite the invention of the obelus (÷) symbol in 1659. The obelus is hand-written by students for math division and is read by SR as, “divide by”. It’s a great symbol for inclusive writing and isn’t available on most keyboards. The “slash” key is, which is why it’s the key we press for a visual shorthand of division.
If the “slash” isn’t announced semantically by SR and is a visual math divide operator, why do we use it to divide written concepts or data? Why not write a “pipe”(“|”), which is announced as “vertical bar”. “Vertical bar” is far more descriptive of a visual divider than “slash”. As we’ll learn later, the hyphen may be better still.
Standard math operator
The ISO 80000-2 standard for mathematical notation recommends only the solidus ( “/”, or “slash” ) should be used for division and the obelus (“÷”) should not. Perhaps the reason is how easily the solidus “slash” is used to type fractions in print: at least in a pre-computer age? Ha!
In school fractions are signalled by placing digits above and below a horizontal rule. When rendered by word processors and although still employing a solidus, the resulting character positions the digits above and below one another. For example, here’s a half ½ rendered from the HTML entity, “
½“, which is announced by SR as “fraction”.
In difference to their guideline, the ISO standard uses an obelus-like pattern in equations. Division is signalled by placing digits above and below a horizontal rule. The number to be divided is above, and the number divided by is below the line.
Surely the best symbol to describe this pattern is the obelus (÷)? It’s announced as “divided by” by most screen readers, too. The ISO standard clearly needs information experience designers on the committee! Ironically if not incorrectly, the standard’s copy includes the use of, “and/or”.
Perhaps the “slash” ambiguity and popular inclusion on keyboards evolved from early print? The number of symbols was limited by the emergence, expense, and constraints of movable block printing. The early “f” and “s” were combined by example and the obelus arrived 100 years after the technology. Perhaps too, the ISO 80000-2 standard’s recommendation of the solidus took no account of the audible experience of Web pages? Is the standard ableist?
There’s room on computer keyboards for an obelus (÷) key.
For writing dates in our UI , the answer is simple. Sure, write it when you must and be certain to indicate when months follow days or days follow months! There’s a reason to avoid the pattern if ever there was one. When is 12/12/2022? OK. That’s an easy one, what about 02/06/2022? Is that February 6, or June 2?
To avoid confusion for screen reader users, enclose the date within a programmatic and inclusive <time> tag. The following is an example of <time> based on W3C Schools.
<p>Meet us at <time datetime="2022-02-14 20:00+8:00">8pm on 02/14/2022 PCT</time>.</p>
- It doesn’t solve all confusions for visual comprehension.
- The time and date may be announced in, or accompanied by the user’s operating system language and not the language specified by HTML metadata declaration. (From informal tests in The time element in Safari and VoiceOver).
Interestingly, the syntax includes hyphens (“-“) and not “slashes”. It’s as if we care more about computer data parsing than our own experience. That’s reasonable when we consider the precision computing needs and unforgivable when we empathise with our readers.
Note: The discussion on the semantic differences between and use of the hyphen (“dash” in some screen readers), minus (
−), and n-dash (
–) is a whole new muse!
As for visual rendering of dates, the “slash” is a convenient divider between the parts of a Web address. Why then, where the programmatic syntax for dates is to use a hyphen do we use a slash in URIs? Let’s not go there. Let’s not. No.
In schools using Arabic numerals (digits 0 to 9), we may be used to receiving teacher’s grades as, 5/10.
- When the “slash” means divide, the answer is 1/2 (½, half, or 50%).
- When the “slash” means “and, or”, then our teacher is indecisive!
The slash context here is, “out of” or “divided by”. Go figure. “Slash!” So, maybe when writing inclusively, we should type “5 ÷ 10”, or perhaps more conversationally, “5 out of 10”?
Note: Did you know there is an HTML entity we can use for the solidus in a fraction? It’s announced as, “fraction”. Cool, yes? Read more in the Codes section.
Conventions are historical
The convenience and convention of the “slash” hides its issues. We may be used to the ambiguity of the “slash” and from an accessibility viewpoint, people have grown used to it. It localises well without translation, too. That may not excuse our designing an ableist experience? For example, an improved audible experience of scores is, “5 out of 10”. That’s not difficult.
It may be that all we need do is confirm the context of the “slash”? When we know the digits form a date, sum, or score we only need to make that clear?
Whatever the intention, the forward slash is often unnecessary and like any conjunction we can improve our writing when omitting it.
When an, “and/or” conjunction is encountered, we should:
- Understand the context
- Rewrite the copy to omit the conjunction
At its simplest, the task of updating “and/or” only needs us to decide between “and” and “or”. More complex concepts may require more effort.
Strategies to rule them all
The following global strategies would create a more inclusive writing and reading environment.
- Add an obelus (÷) to the standard and numeric keyboards
- Use the hyphen to separate date components. For example, 02-02-2022. Software often and already parses the hyphen pattern as a date.
There are some hazards. Using the “slash” may be necessary to fake the appearance of a fraction. There’s even a special HTML code for a lower-angled one (
⁄). We may need to use some additional markup. In the following example, the fraction is announced as, “one fraction two”.
<sup>1</sup>⁄<sup>2</sup> looks like 1⁄2.
Fabulously, Confluence lists the “fraction” symbol in its Insert more content / Symbol menu! Here’s a half created by typing the two numbers and placing the symbol between them, 1⁄2. Now we score 100⁄100 for effort
Our writing “slash” needs care during content design of the visual and audible experience. When applying “Standards” beware that they may not have caught up with inclusive design yet.