Accessibility in Copy [Web applications]

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Disabilities aren’t always obvious or declared. We should not screen for disabilities and we should not shut out any potential users. We write for the Social Model of Disability and currently follow the Web Accessibility Initiative standards.

This is a table comparing the medical model with the social model.

The medical model says:

You are the problem
You need curing
You cannot make decisions
You are not equal

The social model says:

Disability is not an individual problem
Society contructed barriers
Society must remove barriers
Disabled people have the right to equality


The audience for accessible content is everyone. 100% of people will experience disability or impairment at some point in their lives.[1] Types of impairments vary and include visual impairments, neurodiversity, hearing loss, mobility, manual dexterity, and cognitive impairments.


It would be beneficial to consider four personas here.


20 year old student, she has weakness in her hands due to MS. She hates complex password requirements that involve special characters and can’t type long passages.


Carlos is a 50 year old man who moved to the US two years ago. English is his second language. While he is proficient in English he does need extra time to read and write English phrases. He loves a clear basic sentence without jargon.


Sophie is partially sighted and uses a screen reader. She hates that there are gaps in websites (probably when text is embedded in images) meaning that she doesn’t always get the full experience.


Eric is very techie and dyslexic. He likes a UX that explains itself and concise explanatory labels. He hates how certain fonts take away from his experience online.

Accessibility terms

Use the following accessibility terms as outlined by Microsoft.[2]

Use this

Instead of this

Blind, has low vision

Sight-impaired, vision-impaired

Deaf or hard-of-hearing


Has limited mobility, has a mobility or physical disability

Crippled, lame

Is unable to speak, uses synthetic speech

Dumb, mute

Has multiple sclerosis, cerebral palsy, a seizure disorder, or muscular dystrophy

Affected by, stricken with, suffers from, a victim of, an epileptic

Without disabilities

Normal, able-bodied, healthy

Person with a prosthetic limb, person without a limb

Maimed, missing a limb

People with disabilities

The disabled, disabled people, people with handicaps, the handicapped

Cognitive disabilities, developmental disabilities

Slow learner, mentally handicapped, differently abled

TTY (to refer to the telecommunication device)


Considerations when writing

Here are some considerations when writing including the ABC of accessibility, headings and landmarks, ARIA attributes, and clarity.

The ABC of accessibility

Use the ABC of accessibility:

Consider the following guidelines for UX copy[3][4]

  1. How does copy sound on a screen reader?
  2. Use your tone but not at the expense of your user.
  3. Use alt descriptions.
  4. Be more descriptive than Read more for links and buttons.
  5. All microcopy should appear as live text – not as an image.
  6. Readability – permanent text in high contrast.
  7. Write simple copy.
  8. Does this language make sense to someone who doesn’t work here or at your customer’s company?

Headings and landmarks

Use headings and landmarks with correct semantics to provide a clear idea of the page structure. Landmarks can help the user navigate the page.

ARIA attributes

ARIA (Accessible Rich Internet Application) attributes. This can help explain what a user needs to select or to explain what defaults are already selected.


aria-label=”Choose your language. Your current language is English” role=”button”


  • Each button has to be clear in its action. For example replace nonsensical trendy words like let’s go for confirm.
  • Choose link text that is clear and helpful. Write copy for links and buttons that can function without context or work with developers to come up with some alt-text for screen readers.
  • Avoid click here or learn more.
  • Write short sentences and use familiar words.
  • Use words with 1-2 syllables when possible.
  • Use the Hemmingway Editor to measure the readability of your text.
  • If you need to use an abbreviation or acronym, explain it on the first reference.

Writing for screen readers

When writing for screen readers we need to ask 3 questions:

  1. How can I test this?
  2. Why do I care? – consider that readers don’t perceive a full picture of the screen.
  3. Think top-down and left to right

Placing the microcopy in front of the action is critical. The accessible order of elements is: Label > Instruction\Hint > Field

Here’s how Facebook does it:

Image shows a Facebook form and when you hover over the i next to the Languages field, the following text appears "Leave this blank unless the audience you are targeting uses a language that is not common to the location you have chosen above."

And here’s how Walmart does it:

Image shows a form on Walmart's log on system. The label is "Security code" and there is a question mark next to the label.

Note for developers: The elements can appear in any order on screen as long as you set the keyboard focus shift in the correct accessible order. Never place microcopy under a confirmation button.

Avoid directional instructions and any language that requires the reader to see the layout or design of the page.[5] We don’t want people to skip the question or abandon the task.

Alt tags

Alt tags describe images and must be included on all images.

  • If the image is serving a specific function, a screen reading user needs to come away with as much relevant information as someone who has seen the image.
  • If you’re including graphs or charts, include the data in the alt text.

Important text

Screen readers do not see the following:

  • Colour
  • Bold
  • Italic
  • Strikes
  • Underlines

So do not use these styles as the only way to indicate importance. Red text looks like alert text but users of screen readers won’t know the text is red so you need to give a strong visual clue like an exclamation mark to show it’s an alert or important message.


Use gender neutral language.

“Gender-neutral language is a generic term covering the use of non-sexist language, inclusive language or gender-fair language. The purpose of gender-neutral language is to avoid word choices which may be interpreted as biased, discriminatory or demeaning by implying that one sex or social gender is the norm. Using gender-fair and inclusive language also helps reduce gender stereotyping, promotes social change and contributes to achieving gender equality.”[6]


Consider how to test accessibility and put together an accessibility checklist. Consider hearing how your copy sounds using a screen reader.

[1] [Accessed 20/03/2019]

[2] [Accessed 20/03/2019]

[3] [Accessed 20/03/2019]

[4] [Accessed 04/04/2019]

[5] [Accessed 04/04/2019]

[6] [Accessed 05/04/2019]

Write an Alexa skill in 15 minutes

Well, it took my husband, who has no Alexa skills experience, 15 minutes. So if you have 15 minutes, and some development skills (he has 7 years of software engineering and architecture) this is the tutorial for you. If you have zero experience it might take you 30 minutes, it might take an hour, more, who cares, you get to show off a fully fledged Alexa skill! How cool is that?! Please do try it, and if you need any assistance or clarification, just ask.

I created a Github repository that has all you need to get started. The only prerequisite is an AWS account. On my Github tutorial you can find, instructions, an index.js file, and a messageResponses.js file. When you have the whole thing up and running I suggest changing some of the content around, and maybe adding in some more. I’ll be disabling comments because of spam but I would love to hear what you think so send me a message on whatever platform I post this on. 

Art and code

My masters in Digital Arts and Humanities at UCC taught me a lot about creative applications for technology. In our History and Theory of Digital Art module we were tasked with creating digital art. Digital Distortion is a commentary on how we represent ourselves on social media. Everything we put up is carefully curated by ourselves with our digital selves ending up much further away from our actual selves. To represent this I chose to put my own image through a number of processes both digital and analogue until almost unrecognisable and use as many of my own digital image processing skills as possible.

ART LINK: [Turn on closed captions]


Using a geometric patterned background, I took a large amount of “selfies” as an homage to the popular social media technique. The background image used is deliberately unnatural to further show how we are distorted on social media. All of the selfies were then heavily filtered to the same level as my social media pictures. Angles were carefully chosen to display my social self in the best possible light. I included one picture taken through a mirror to analogise self-reflection – when you look at your social media self you see it in black and white and can be aware of the distortion but blinded by the beauty of this carefully curated self.

Digital Process
I used three separate means to create the glitch, Notepad++, Audacity, and a bespoke Python glitch program that I wrote myself for this project.

Analogue: The piece Analogue was created using Notepad++, the image was converted into a RAW file and then opened as a .txt file in Notepad++. Data was deleted, copied and pasted, added, until a desired glitch effect was noticed.

Echo: The piece Echo was created using sound engineering software Audacity. The RAW file was imported into the software and an echo filter was applied to the resulting “audio” waves that were generated by the import.

Faces: The piece Faces was also created using Audacity, this time multiple filters were applied to the RAW file before it was then exported and converted back into a JPEG.
Algorithm: Algorithm was created by me using Python. I wrote a program that takes in an image that contains an algorithm that selects a random array of pixels and places them in another random location creating a glitch effect.

Inversion: Inversion was created using another method in the program I wrote. This takes all the RGB values of a pixel and inverts them to create the colour effect. I also applied the same effect used in the piece Algorithm for further distortion

Grey: Grey, a method in takes all the RGB values of a pixel and divides them by 3, creating a grayscale effect. I also applied the same effect used in the piece Algorithm for further distortion.

I converted my own images into sound, using the RAW files of the images to create a sonic landscape for my art. All sounds are made using clips from my own photos which were further distorted in Audacity using effects.