Improve your blog’s accessibility

Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with disabilities. When sites are correctly designed, developed and edited, generally all users have equal access to information and functionality.

Wikipedia

The Hypotheses blogs use the WordPress software as a basis. Making the WordPress software and, in effect, the Hypotheses blogs accessible for both reading and writing is largely the responsibility of the WordPress teams.
See the news from the WordPress Accessibility Working Group.

As an author publishing on Hypotheses, you are free in the writing and formatting of your text, as well as in structuring and customizing your notebook as you wish (within the limits of the possibilities offered on Hypotheses). While making the WordPress software accessible is the responsibility of its development teams, making your content accessible is up to you.

Here are some best practices identified to improve the accessibility of your blog:

Summary

• Text formatting
• The colours
• Medias

Text formatting

Text justification…

… is not a good practice on the web and contradicts the recommendations of the W3C. Indeed, a justified text on the web will be with fewer options than on a word processing software, and does not create a justification that avoids “rivers of white” in the middle of paragraphs, nor to keep a constant space between the letters of a word. Spaces between words can thus slow down the reading, and inconsistent spaces between letters complicate the location of boundaries between words. A justified text on the web can then increase the visual fatigue of readers, and cause cognitive disorientation, especially for dyslexic people. In addition, the more or less long lines of a text aligned on the left allow the eye to find its way more quickly in a scroll text of a web page.

To read about text justification on the web: Text justification is a key accessibility issue in documents, by Media Access Australia

Using heading levels

Using “Heading” blocks to structure the content of an article, rather than signifying heading levels with bold, color or a larger font size in “Paragraph” blocks, makes this structure accessible to the entire readership of the article, human or robot. The consistency of the structure allows a mental representation of the content hierarchy and therefore an easier navigation in the content, especially for people using screen readers or keyboard navigation, the heading levels being used to navigate in a content. A well structured web page with heading levels is also better referenced by search engines.

The title of an article has a heading level in its html form. The heading levels used in the content of the post can be then etc. The “Heading” blocks and heading levels are recognized as such by robots and screen readers and allow the summarization of the post. It is therefore advisable not to skip a heading level (e. g. from a heading to a heading) for aesthetic reasons (size, colour, spacing), since this makes the articles structure less readable: the graphic theme applied to the blog should be chosen taking into account these headings’ characteristics.

More about headings : Headings, by Accessibility at Yale

Providing useful link descriptions

One of the major advantages of writing on the web compared to paper is the possibility of creating links between contents, especially in the form of hyperlinks. The link consists of a web address (URL) associated with a word or a piece of phrase that constitutes its label, and it is recommended to choose this label so that it is as descriptive as possible of the link to which it refers, to be understandable out of the context of the sentence or article. Indeed, people using screen readers are read a list of links from the web page currently opened (for example an article). It is difficult for them to find their way around a list consisting of, for instance:

• link
• download
• click here
• here

Similarly, it is better write the name of the website and link to its URL rather than write the entire URL – for instance, link to hypotheses.org rather than to https://hypotheses.org/ (reading these two links aloud gives an idea of the best readability of the first one).

More about link descriptions : Link Text and Appearance, WebAIM

Providing details on the destination of links

Best practice regarding descriptive links applies in particular to links to downloadable material. For this type of link, it is advisable to specify the format and size of the file that will be loaded when the link is opened. This way, the reader can know right away if downloading this file will exhaust their Internet package, if their terminal can read the format, or if it is better not to click for the time being.

Similarly, when a link points to a web page or document written in a language other than that of your article, it is best practice to specify the destination language at the link level so that the reader can choose to click on the link based on this information.

Finally, according to the W3C, it is not generally recommended to forhttps://www.w3.org/TR/WCAG20-TECHS/G200.htmlce links to open in a new tab or browser window. Indeed, the forced transition to a new window or tab can disorient people in their understanding of the digital space in which they find themselves, especially for people with visual impairments. Changing tabs or windows breaks the thread in the web browser, preventing the person from going back to the previous page.
If opening in a new tab or window is nevertheless chosen, it is recommended to add a note indicating it at the link level.

The Hueman graphic theme can display an icon next to external links. If this icon indicates that a link leads to a webpage external to the blog, it does not mean that the opening will be done in a new tab or a new window.

More on descriptive links : Write accessible links, by AccedeWeb

Keeping the default text size

The graphic themes available on Hypotheses follow the accessibility recommendations for font sizes (16px to 18px on a computer screen for text matching the “Paragraph” block of the editor) by displaying a default 16px text font size. Indeed, the code of the graphic theme (its CSS style sheet) defines the default font size, font choices, and possible color options.

In the text editor, it is possible to change the text size of a “Paragraph” block in the “Block” tab of the settings column, either by specifying a number of pixels or by choosing from the predefined sizes “small” to “huge”. By default, the predefined size is “normal”, which corresponds to 16px. As this size respects accessibility standards, it is recommended not to write entire text blocks in a smaller or larger size.

In the case of copying and pasting text from a text document or an external web page, some original formatting markers can be retained. As a result, the text may not adopt the default size defined by the graphic theme. It is recommended to clean a text from its formatting before pasting it into a post to remove these residual markers.

With the Hueman graphic theme, it is possible to adjust the font size of the text, which is 16px by default. Here again, it is recommended not to deviate from the size range of 16px to 18px for optimal readability.

Current web browsers allow to increase the size of the fonts very simply. It is therefore recommended to keep a “standard” font size and to allow the reader the possibility to adjust the font size according to his needs.

The colours

Ensuring that the contrast between the text and its background is high enough

The graphic themes available on Hypotheses often allow you to customize the colour of the background pages, and less frequently that of the text itself. Text/background contrasts can also occur in the header image, “Image” widgets, images containing text inserted in your content, or coloured text inside the articles. It is important, for all these elements, to check the contrast between the text and its background.
The tanaguru contrast finder online service, for example, allows you to check and correct the contrast between two colours, in accordance with web accessibility standards.

Not giving information only using colour

“Click on the red button”, for example, is not executable information for people who do not distinguish the colour red. This is one reason why, as a standard feature, links are indicated by text in both colour (often blue) and underlined.

Thus, in web writing, it is not a good practice to underline text that is not a link: underlining looks too much like linking, and underlining text that is not a link can mislead readers.

The media

Adding alternative text to images

Adding alternative text (“Alt” attribute) to an image makes it possible to make the information normally given by the image accessible when it cannot be loaded (limited connection) or viewed (screen reader users or indexing robots). The information to be given in this “Alternative Text” field differs depending on the type of images:

• The image contains text that has a function (e. g. the image is a button marked “Download”): note in “Alt” the function expressed by the image;
• The image contains text that is not in the text surrounding the image: note this text in “Alt”;
• The image does not contain any text but is necessary for the understanding of the article or page: describe the meaning of the image in “Alt” – if explaining the image becomes long in the alternative field, it may be interesting to explain it in the text around the image, as the explanation can probably help others to understand this image.
• The image has a purely decorative and aesthetic purpose: not writing anything in “Alt” helps to avoid unnecessary “noise” and allows people to concentrate on the text.
• The image contains information otherwise given in the text around the image: in “Alt” can then be noted “See text”.

When an image is clickable and refers to a web page or document to display or download, the “Alt” attribute should indicate the destination of the link rather than describe the image itself.

More about alternative text on images : An alt Decision Tree, by the Web Accessibility Initiative

Offer alternatives to audio or video

It is recommended to provide your blog readers with textual alternatives to multimedia content, when this content is not purely decorative and is necessary for the understanding of the article or page.

In the case of videos, accessibility can be improved in the video itself, by providing subtitles, sign language interpretation or audio description. These elements must be integrated into the video itself, before it is inserted into the blog.

On the blog itself, it may be best practice to provide a text transcription that can be displayed or downloaded, or any other file or link that gives access to an alternative to audio or video media.
Disable automatic media playing

Opening a web page, being instantly and unwillingly subjected to the sound of an audio or video file, having to find out which tab of the browser makes this sound, then on the web page which button can be used to stop it, is unfortunately still a common situation. Moving images, sound, and the shock situation caused by their automatic launch can be a source of frustration for everyone, and a source of stress for people with cognitive disabilities or epilepsy. An automatically launched video or audio file can make the web page completely unnavigable for a person using a screen reader, since the sound of the media can cover the screen reader’s voice.

In the case of videos or audio players inserted as embedded content from external services, settings to prevent automatic play are usually found on the original site and in the iframe code configuration for embedding them.

In the case of a video or audio file hosted on the blog, the automatic playing settings are located in the “Block” tab of the settings column. In compliance with web accessibility recommendations, automatic reading is disabled by default. For similar reasons, the control bar (play, pause, volume) is visible on default videos, and although it is possible to hide it in the “Block” tab, it is not recommended to do so.

---

This article was written as part of a work on accessibility conducted by OpenEdition, with the help of Valérie Mansard, Digital accessibility referee for non-reading audiences and editor at ENS Editions.

Featured Image: Open by Kasper Jensen under Creative Commons BY-NC-SA license

---

---