Are you developing your website for many types of users, or are you primarily developing for people who access websites in much the same way as you do? Do you know how dyslexic users, people who are colourblind, people with impairments, and others navigate the web? This is the final blog post in a series of 3 that cover websites and accessibility with a role-based approach. This post is meant for web editors. The previous posts were intended for web designers and for web developers.

Page titles

As a web editor you are responsible for the content published on your website and its accessibility. Do you know how to support accessibility when you write texts and add images and links on a web page?

In a CMS, you give a web page a title or name when you create it. In some systems there is also a specific field for this called "Title." It's important that this title is descriptive of what the page is about, because it's shown in the top of your browser and is the first thing on a web page to be read by a screen reader.


When writing text for web pages, consider the fact that some users can't get an overview of a page visually, as opposed to structurally. Make sure that pages are divided into logical sections, with each section given a descriptive heading. You can use several levels of headings: heading 1, heading 2, etc. (in the code <h1>, <h2> etc., so that assistive technologies can render them as headings).

Because of low vision, some users will perceive a web page very differently from the way other users would visually perceive it. Make sure to avoid giving important information solely by the use of colour or with an instruction requiring sensory skills. For example, avoid writing things like: "… you can read more about the event in the blue box to the right."

It's fine to write something like this if you supplement it with something that all users can find, such as an additional text: "… you can read more about the event in the blue box to the right by the heading 'Events in March." This way you're also giving details that all users will be able to find.

If you change the language in the text, make sure you state the language of that piece of text. In the code this is done with the attribute lang="" for the text unit. A good CMS will allow you to highlight the piece of text and choose language from a drop down menu.


When you add links to a page, write link texts that make sense when read out of context. For instance, avoid using link texts such as "Read more," "here," "Click here," "publication," etc. An example could be: "You can read more about the Assistive Technologies event here." Another example could be writing: "You can read more about the Assistive Technologies event here." It would be better to write "You can read more about the Assistive Technologies event here" for example. This way you are providing a link text that in itself is a good indicator of what the destination page is about.


When you add images to a web page, consider the fact that some users cannot see images and need a text alternative. In most CMSs this is stated as "alternative text" or "alt text." The text given here is not visually displayed on the page, but is hidden in the code to be accessed by screen readers. (The alternative text is not the same as a tooltip: The text displayed when you hover over the image called "title").

Try to close your eyes and visualise what information you need if you cannot see the image. Describe the purpose of the image and not necessarily what the image is of. If the image links to a new page, it is important to describe where the link goes to. If the image is solely used for decorative purposes, creating an ambience or a visual context, it should have no alternative text. If the image contains information, that information should be given in the alternative text.

Avoid using images of text. This means that you should avoid, for instance, writing a text in an image editing program and save it as an image. Many of the types of software that reads text aloud (for instance those used by dyslexics) cannot read images of text. This is because you can't highlight text within an image to have it read out loud to you. (Some of these types of software can read alternative texts but far from all. They should not be confused with screen reader software used by the visually impaired. Those software types are much more advanced).

Video and audio

If you are using video or audio clips on a web page there are several criteria to consider, such as captions and audio description on video. Audio description is an extra track that lets a visually impaired user know what's happening on the screen. If you are not able to provide your videos with audio description, give an alternative in the form of a transcript that is uploaded or linked to from the page. Be aware that without audio description you cannot be AA compliant but only A-compliant.

If the content is solely visual (no sound) or only audio (no visual) then a text version is an accepted alternative on both levels.


When using a list of items make sure to use the function for this that is built into the editor in the CMS. This will ensure that the right and accessible code is entered for lists. Avoid just making dots that looks like a list (such as asterisk, dash etc.).


Finally, when using data tables with information, it's important to indicate headings for rows and/or columns. The way to do this is very CMS specific. In some cases the editor provides an accessibility tab where this information can be entered when using data tables.