Accessibility, the wiki, and you

To begin, I’m not an expert on accessibility in any way. But I do care about it, and I consider accessibility to be one of the core goals that must be considered in any public project.

Why accessibility?[]

Here are some examples of accessibility features that can be found in everyday life:

• A wide door with automatic or semi-automatic opener and a low step. Great for wheelchair users, parents with strollers, or just someone carrying lots of luggage onto the bus.
• Automatic voice announcements on upcoming stops for the bus or train. Great for blind people, new visitors, or when it’s dark outside.
• Well-structured information. Great for people with cognitive issues or people who are just in a hurry to find a specific piece of information, like if they should get off this bus stop or the next.
• Well-separated link texts and buttons of sufficient size. Great for people who have problems with fine motor control or people with large fingers using smartphones. Or for everyone on a moving bus rocking back and forth, be it a button on the phone or the button to call for the bus to stop.

These examples are not chosen at random, because a disability appears in the interaction between the person in question and the environment they are in, and can be either permanent or temporary. They also match with four different groups of disabilities:

• Gross motor function
• Sensoric
• Cognitive
• Fine motor function

But good accessible design and features also tends to become taken for granted and we only see them when or if they suddenly go missing. Accessibility should thus be a core goal in any public project for a number of reasons.

• Good accessibility is easy to include when it is considered from the beginning and as part of the initial design, but it is hard and expensive to add later.
• Good accessibility helps you reach more people.
• Good accessibility helps everyone.

One factor to be aware of is that what is accessible design for one person might be inaccessible for another. This is perhaps most easily exemplified by the perennial discussion about light or dark themes. Some of this might be driven by personal preferences, but the way we discern light means that for some people it is not a choice or a preference: they need the dark or the light theme to be able to read the text at all. Another example is that for people who use wheeled assistive devices it is better that the ground is smooth, while blind people often are helped by varied structures in the ground that can be discerned tactilely with the feet. But this is unlikely to be of relevance to us in our context as wiki caretakers, apart from making sure we have proper light and dark themes.

Improving accessibility can also be one of the best ways to improve general usability.

Accessibility and the ’net[]

Most computers, web browsers, and HTML already have some accessibility functionality built in. Other assistive technologies can be installed or added to them for people who need that. However, it is possible to lessen or destroy the effectiveness of this, inadvertedly or not, by choices of design or technology.

Examples of computerised accessibility features include things like voice assistance, e.g. Apple’s VoiceOver, the ability to set everything on the screen in high contrast mode, to resize the text, or use discrete rather than continuous ways to navigate the elements on the screen—think tabbing through the elements in a form, but through everything on the page.

Visual considerations[]

Visual contrast of background and content is perhaps the most important factor for readability. The default styling for fandom.com already gives decent values in both dark and light themes here. While it is possible to change this using CSS or the Theme Designer, the freedom also brings with it the responsibility to not mess it up for users who literally see things differently. Not everyone knows how to reach for ?safemode=1.^{[Note 1]}

Colours can be a great visual aid, but not everyone perceives colours the same way, and adding too many coloured elements to a page, especially if they are coloured in different ways, can overwhelm the page and make the actual text hard to read.

• Make sure every CSS rule involving colours take the classes .theme-fandomdesktop-light and .theme-fandomdesktop-dark into account, unless they set both the background and the foreground colour, or use variables which take the themes into account.
• Do not make text smaller. The default text size on fandom.com is already on the small side, and shouldn’t be made smaller without very good justification. A font change will likely mean adjusting the font size and possibly line height as well. I have more discussion regarding fonts and typography in Some thoughts on typography.
• Include ALT texts for all pictures.
• Provide good link texts.

ALT texts[]

The ALT text was one of the earliest assistive elements of HTML, but it has been widely misunderstood and misused at times. Do not use it as any kind of popup text or caption: it is a replacement for when the image cannot be displayed.

Writing good ALT texts[]

Here are my own rules of thumbs when it comes to ALT texts:

• For purely decorative images, use [[File:Example.jpg|alt=|]] (the empty string) as the ALT text. That way screen readers know they can ignore the image.
• For images with text in them—which is generally not a good idea—use the image text as the ALT text.
• For images which serve a function the ALT text should describe the function, e.g. "cut" rather than "scissors" for an icon that cuts the selection.
• For other images, describe the content of the image, with a focus on the purpose the image plays on the page. The same image might be used on a page on fashion design, art history, or Swedish literature, but the respective ALT texts will likely focus on very different aspects of the image.

A side benefit of writing good ALT texts is that it is easily picked up by search engines and helps index both the page and the picture.^{[Note 2]}

ALT text issues on fandom.com[]

There are sadly some issues with ALT texts are presented when combined with galleries:

• Galleries in portable infoboxes will assign the image caption as the ALT text, and not the specified ALT value. This problem does not appear with singleton images in portable infoboxes.^{[Note 3]}
• Navigation galleries on mobile will use the file name as the ALT text, and not the provided one or even the caption. This should serve as a reminder to make human-readable file names. “Portrait of Bellman in 1779.jpg” is at least somewhat understandable; “IMG237986.jpg” is not.^{[Note 3]}

Link texts[]

Some web browsers are capable of presenting a list of all links encountered in a page without the intervening texts. This can be useful in specific circumstances, but it requires that the link texts are semantically meaningful. A sequence of links with each of them labelled "click here", "read more", or "information" is not helpful in any way. The wikitext syntax at least discourages that type of labels for links, but it is something to consider in all forms of web pages.

Another factor that arises with discrete navigation of links is that repetition of links can be an annoyance. Here again the navigation galleries are not as good as they should be, presenting each link twice, provided the image has an ALT text and a caption. One way to get around this could be to make a custom template, perhaps using CSS flex, with unitary links of image and text, but that is rather excessive and labour intensive. Using an empty ALT text is not a good idea, since that will present as a link without any text at all, but which still has a target, which is lousy in every way. We will just have to hope that fandom.com improves the way navigation galleries are constructed behind the scenes in this regard too.

From an accessibility standpoint, a link should have an easily understandable link text, hopefully have some context which explains why it is on the page in the first place, be separated from other link texts, and also be easy to pick out without overwhelming the elements around it. This also means that most navboxes have lousy accessibility. I have more discussion on navigation in A Reconsideration of the Navbox as a Portable and Modular Infobox, or the Navinfobox Blog.

Text and markup[]

Well-structured and easily understandable text is in itself an accessibility consideration that benefits everyone. With proper use of headings the page will also gain a clearer, explicit, and navigable structure.

I have also noted that text that for some reason is placed directly within the body element, and not contained in e.g. a p element, is not only trickier to format with CSS, it is also treated to be less meaningful by at least Google’s search engine. I wouldn’t be surprised if screen readers or other assistive devices also have issues with such text. One way to handle that is to make sure the underlying wikitext is written with clearly delimited paragraph breaks using empty lines.

Elements like images or pull quotes should be placed together under the section header they belong with. It helps accessibility and it helps to read and understand the underlying wikitext.

Further reading[]

• Apple’s accessibility guidelines—readable and thorough, though focused on apps rather than web sites.
• Tips for getting started with web accessibility from the W3C.
• Designing for colorblindness—a description of how a particular person experiences colours.

Notes[]