Zoom was created in 2011 but it didn’t take off until its use during the pandemic – when it became the de facto video chat tool. There can be no doubt that it’s a powerful and valuable communication tool, however, it also has some major accessibility issues. In this short article I set out what some of those issues are and suggest ways to get around them – where possible.
For example, Zoom doesn’t always work well with screen reading software.
If you are going to be using the chat function you can use a ‘chat wrangler’, i.e., a person who monitors the chat, tells the group of new messages, and reads them out. Or you can separate out the chat and use an accessible chat application instead of the one built-in to Zoom.
Any important information, such as links should be sent to participants by email after conclusion of the session.
The Whiteboard function in Zoom is not accessible to screen reader uses – as it is the equivalent to posting an image to the screen – but it is an image without a text description.
If you intend to use the whiteboard – be sure to make the whiteboard content available in an alternative accessible format.
If you are using the whiteboard – ensure you are keeping screen reader users up to speed with what you are doing and what you are writing on the board.
The Share Screen function in Zoom is only screen-reader-accessible to the individual sharing their screen. If the session is going to involved screen sharing then seek out an alternative to Zoom for the session. There is a list of the most accessible video chat software at, the Big Hack website.
The Zoom polling tool also has accessibility issues for presenters and participants with some impairments (as reported on Yale University accessibility page). As with the chat example above, you could look at using a third-party tool instead. For example, Mentimeter have a polling tool; they write about inclusivity in their accessibility statement – which suggests that it’s accessible. However, I’ve never used it, so check it out first.
Survey tools are necessarily the same as online poll tools but they might be worth checking out to see if they suit your purposes. The University Of Washington’s has a review of online survey tools. And I see SurveyMonkey has information about how you can make their surveys accessible – so that may also be worth investigating.
Jim Byrne December 2021
Arial is a sans serif typeface, designed in 1982, based on Monotype Grotesque. The font has a similar proportion and weight to Helvetica.
It is a font with a contemporary look. Since 1992 it has shipped with every version of Microsoft Windows, which has helped it become ubiquitous.
It is a favourite of desktop publishers, though less so with designers; who think it inferior to Helvetica. The story goes, that it was designed primarily to avoid having to pay royalties (to Linotype) for the use of Helvetica.
It is rarely recommended for print work (though it is a print font). Helvetica is considered a better-looking, more flexible font.
Arial is recommended by RNIB and other organisations concerned with accessibility. If you search for guidelines for document accessibility they all tend to say, use Arial, with a minimum size of of 14pt.
However, I am not aware of any research that shows Arial to a better font than similar sans serif fonts. I think it’s more likely that it was the sheer ubiquity of this sans-serif font that led to the recommendation.
There are similar contemporary-looking, clean and easy-to-read fonts that would do the job just as well. I.e. Calibri, Century Gothic, Helvetica, Tahoma, and Verdana or Myriad Pro.
Note that all of the above fonts are sans serif. Serif fonts are rarely recommended – as more ornate fonts are considered more difficult to read. On lower resolution computer screens the serifs can be distorted, making the words look blurry.
Having said that, slab serif Fonts (a type of serif typeface characterized by thick, block-like serifs) such as Rockwell, Clarendon, and Museo Slab are considered easy to read and accessible. They tend to be used for headings rather than body text.
Photo: “Pool of Knowledge” by Ian Muttoo is licensed under CC BY-SA 2.0
ARIA stands for Accessible Rich Internet Application. ARIA was designed to make Web content and dynamic applications accessible to disabled people – by providing a list of new attributes that can be added to HTML elements.
These attributes are understood by browsers and assistive technology – adding functionality to help make web content more accessible.
Here are some ways that ARIA makes websites more accessible
There are two categories of ARIA attributes. ‘Role’ attributes and ‘states & properties’ attributes. These attributes can be added to elements manually or they can be added dynamically, i.e. using scripts.
Role attributes are added via role=”name of role goes here”. There are six different categories of role attributes:
<div id=”nav” role=”navigation”>…</div>
Everything within this <div> will be recognised as being part of the navigation section.
When landmarks have been added to a page, screen reader users can jump directly to the different sections. The name of the attribute makes the function of each section clear for users.
<input type=”search” aria-label=”search text” >
<input type=”submit” value=”Site Search”>
You may have noticed that I used an additional ARIA attribute in the above example, the aria-label. The aria-label attribute is a way to add a text label to an element. The text label is not visible on the screen but is read out by screen readers.
Examples of landmark attribute use:
Here is an example of using the ‘main‘ landmark
<h1>Guide to Accessible Website Design<h1>
…. main content area of page ….
There can be more than one section on a page using the same landmark role. For example there could be several navigation sections on a page. When that is the case you can use the aria-labelledby attribute to help distinguish between them. For example,
Example 1: the main navigation
<div id=”mainnav” role=”navigaton” aria-labelledby=”mainnavigation”>
<h2 id=”mainnavigation”>Main Navigation</h2>
…main navigation links here …
Example 2: the right-hand column navigation
<div id=”rightcolunnnav” role=”navigation” aria-labelledby=”rightnavigation”>
<h2 id=”rightnavigation”>Right-Hand Column Navigation</h2>
…right-hand column navigation goes here …
The crucial detail to note in the above examples is that the value of the aria-labelledby attribute is the same as the value of the <h2> id attribute – thus connecting them. In long-hand what is being said is, ‘this heading value is the label for this navigation area’. So the main navigation area is labelled as, ‘Main Navigation’. This is what screen readers will read out as the label for that navigation area.
I mentioned earlier that there are 6 different categories of landmark roles, so to finish this short article here is a summary of each.
Non-profits need to ensure their websites are accessible. This jargon free guide will help.
Align your text to the left and leave it ragged on the right. Left-aligned text increases reading speed. The straight left edge helps to anchor the eye when starting a new line.
Never fully justify text as it can create serious readability problems. Even if you personally like the look of fully justified text, don’t do it. Word spacing is likely to go awry and you will end up with large gaps between words and ‘rivers’ of white space running down your pages. Those rivers make reading your content difficult, if not impossible, for people with dyslexia. Anything other than left-aligned text can cause problems for people using screen magnifiers.
There seems to be little agreement on what is the best line length for optimum reading speeds. The most commonly held view is that limiting line length to 9 or 10 words can increase speed and comprehension (based on the assumption that the eye can only focus on about 3 inches of a page at a time). However recent research appears to show that the rules that apply to off-line print don’t necessarily apply to online print.
It is suggested that line length can actually be longer for online content. However, having said that, don’t go beyond about 80 characters as at that point readability will start to suffer.
Reading speed and user preferences are not simple matters, consider the following conclusions by Melissa Youngman and Dr. Lauren Scharff (1998)
“Users read faster when line lengths are long, although they tend to prefer shorter line lengths. When designing, first determine if performance or preference is important. If user performance is critical, use longer line lengths to increase reading speed. However, if user preference is critical, use shorter line lengths.” Usability.gov
Set the leading larger than the default – as a rough guide 1.3em of leading (130%) will make a big difference to the readability of a web page. Leading and line length however are related; the longer the line the bigger you need to make the leading.
Newspapers have very short line lengths and very little leading. They do this so that they can fit as much text into a small space as possible. However, given the variable nature of the devices people use to view web pages, we can never be sure what the line length is going to be for every user. In relation to leading my rule of thumb would be, if in doubt go bigger.
As an aside: you might be wondering why line-height is called ‘leading’. Well, in the olden days typesetters used pieces of lead to set the space between text lines. If you like typography and typography jargon – which I do – here’s a couple more. The space between characters is called kerning and the space between groups of characters is called tracking.
Need more exciting typography jargon? Here’s a glossary of typography terms.
Choose a font that is suitable to your subject matter. An article about ancient manuscripts can justify the use of a flowery old font whereas an article about the design of modern art galleries can’t. For the article about the design of modern art galleries you will be looking at using a clean and uncluttered san-serif font.
Don’t use more than two fonts on a page. It will look like a ransom note. Clearly that will be distracting for visitors and draw attention away from your content.
Off-line, headings are commonly set in a sans-serif* font, with body text set in serif. However, on-line, sans-serif are often used for both headings and body text; the cleaner outlines of the sans-serif fonts tends to make them easier to read on low resolution screens.
Don’t mix serif and sans-serif fonts in your body text, as it makes you look like an amateur, which isn’t good. You may not have considered it as important but poor typography decisions can damage the credibility of you and your organisation.
* Serif fonts are those with little decorative flourishes on them and sans-serif fonts are the clean and tidy ones. Compare Times New Roman with Helvetica and you will get it.
Avoid using italics for small text sizes. Italicized fonts can look particularly bad at small sizes as italics are not easy to render using a square pixel grid. If you must use italics, avoid using them for large blocks of text.
Don’t use all caps for bodytype – or even capitalise all words in headings. The uniformly of size and shape of capitals make them harder to read than lower case letters.
Readability is increased when only the first letter in a heading is in capitals; each capital – being less recognizable – acts as an interruption to the eye as it scans across the text.
Ensure good contrast between the text colour and the background colour. If the contrast between your text and background colours is low, some of your visitors won’t be able to access your content. That’s why the WCAG contains guidelines for colour contrast. For complying with WCAG AA standard text the contrast ratios need to be 4.5:1 for standard text and 3:1 for large text. Large text means 14 point and larger (typically 18.66px).
Make it easy for visitors to understand what is a link and what is not a link. Don’t rely exclusively on mouseovers to identify links, as this can be confusing and reduces usability. (From Usability.gov).
For service based websites in particular, arrange your text for scanability, i.e. have lots of headings and provide the most important ideas at the start of paragraphs. Use lists rather than dense passages of text when possible.
Most of your visitors will not be interested in reading every word on your page. So make it easy for them to find the information they are seeking quickly by using headings as signposts; signposts for the various issues and topics you are covering in you text.
Use a writing style and language that is appropriate for your audience. Don’t dumb down or dumb up. Think about who you are writing for and write for that audience.
Ignore the idea that you should never use jargon. If your audience expects it and when using it will actually make your meaning clearer, use it.
On the other hand if you are not writing for a specialist audience don’t try to be clever by using jargon just for the sake of it. Think about your audience and tailor your style to suit.
Don’t strive to use ‘easy read’ thinking that that will make your content accessible to a wider audience. It will accommodate one part of your audience but it will put another part off (probably the larger part). Easy read is designed for people with learning difficulties – an easy read version is an alternative version, i.e. a version aimed at a particular audience.
Contact me If you value experience (over 20 years as a web developer) and unrivalled technical know-how. Do you need a new beautiful responsive, accessible website? Get in touch. Tel: 07810 098119.
[contact-form-7 id=”652″ title=”Services contact form”]
For as long as I can remember I’ve puzzled over whether or not to put in default characters in edit boxes and text areas in my web forms. On the one hand if I don’t my page will not will not pass Guideline 10.4 (WCAG 1), and will have no chance of WAI AAA compliance.
Guideline 10.4 exists to ensure visitors using some older screen readers (which don’t recognise empty form fields) – can fill in web forms.
Unfortunately, if I add default text in my form fields I create problems for another set of users, i.e. those who have to delete my text before entering their own. I also create additional work for my forms processing script; which has to check for, and remove any remaining default characters (many people don’t bother deleting the default characters when adding their own text).
I have gone through periods of not adding default text – and having to explain why my forms don’t pass AAA web accessibility tests – and adding text, and dealing with the associated problems. I had resigned myself to the thought that this was one of those web accessibility problems that has no simple solution.
Here is an example from a field in my comments form (only the relevant attributes are shown).
<input type = "text" name = "membername" value = "Name" onfocus="if(this.value=='Name')this.value=''">
Fantastic – one more accessibility compliance problem solved. Get back to me if you are aware of any issues with this technique that I have failed to appreciate.
Links and references
In this tip I recommend you check out a new Toolbar for Internet Explorer developed by Steven Faulkner, of the National Information and Library Service (NILS). Support for the toolbar is confined to Internet Explorer on Windows, so I haven’t been able to try it out myself (I use a Mac) – however, Gez Lemon of the website Juicy Studio is giving it glowing reviews – and I trust his judgement.
According to the blurb, ‘It is designed to help the user to interrogate aspects (structure/code/content) of a html document that can have an affect on the accessibility of that html document. ‘
It does all sorts of things I would find useful as a developer of accessible websites (validation, screen resolution changes, CSS on/off, links to online checking tools and so on), so I think you will find it very useful. You can find installation instructions, and a full feature list for the accessibility toolbar on the website.
The Web developer tool for Firefox is also worth checking out: http://www.chrispederick.com/work/firefox/webdeveloper/ – and it is according to Mike Pepper, ‘bloody good’.
Although client-side images are preferred over server-side image maps – as equivalent text can be provided for each image map ‘hot-spot’ – server-side image maps are sometimes necessary. For example, a server side image can be used when the active regions of a client-side image map cannot be easily defined using an available geographic shape. In such cases the answer is to provide redundant text links relating to each link provided by the server side image map.
The following markup example is typical of the code used to reference a server side image map.
<a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" > </a>
The web pages accessed by the clicking the mage map in the above example would be completely hidden to someone using a screen reader or a text-only web browser, as there is no alternative way of accessing the links provided.
An example of the server side image with alt attribute added and an alternative set of links to the same content:
<a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" alt="Alternative text links are provided at the foot of the page."> </a>
You then make the following links available at the foot of the page,
<p><a href="about.html">About Us</a> | <a href="research.html">Research</a> </p>
As you can see in the example above the alt attribute provided information about where to find the text based links. The alternative text based links provided at the bottom of the page imply that the image map has two hot-spots, one to find information about the organisation and another for information related to research.
Yes, you can use all the ‘stuff’ that as a designer you deem appropriate to your audience and message, and still have a site that is accessible, and passes ‘Bobby’ (and other accessibility tools) accessibility checks.
However, what is required when using these technologies is a bit of clear thinking about what their purpose is on your site, and how, if the content is important, their functionality or message can be provided in alternative ways.
Admittedly it is not all easy, captioning of multimedia for instance is a specialist and difficult skill to master, but most accessibility techniques are not ‘rocket science’ and will actually add to the ‘richness’ of the experience for your visitors, rather than detract from it.
When creating text for your alt attributes always add a full stop at the end of the text. This will help people who are using screen reading software to differentiate the image label from any surrounding text.
It is also a good idea to add a full stop to the end of each item in a list – helping to make the distinction between each item clearer for those who do not have any visual clues.
Other posts in this category