This accessibility checklist is designed to be a fun tool to help you make your wiki more accessible, a starting place if you will. It doesn't cover absolutely everything you can do, but some key areas that could make a big difference to readers on your wiki. Read more about what web accessibility is, and why it is important.
How to use this checklist
- Use this checklist here on Community Central, or copy and paste it over to your wiki where you can customise it for areas important to your community
- The checkboxes are personal to the user, meaning nobody else can see what has been checked
- If you need advice on meeting some criteria, please read the corresponding Help pages in the table. You can also reach out to community members in the #accessibility channel in the Fandom Discord server.
- This list could be daunting for a large wiki with thousands of pages. To make it easier, try targeting:
- The Top 10 most viewed pages per Special:Analytics on your wiki first. This ensures your most popular pages are accessible, which more people are viewing. If you don't have access to analytics, try reaching out to local wiki admins
- Pages for new releases which readers will visit more
- Policy pages the community visit to help them contribute to your wiki
- Using Table Progress Tracking, create a custom list of articles to work on!
Images
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Ensure alt text is added to informative images. This means screenreader users won't miss out on important information the image gives when reading your content. | For this image from Encyclopedia SpongeBobia, alt text could read "SpongeBob standing in front of a packed audience with a spotlight on him. He's wearing a red hat and suit with gold decoration on the hat, shoulders, arms and body." | Read more about image accessibility |
|
|
Captions should not duplicate alt text, and should add context to the image described in the alt-text. This is so screenreader users are not receiving the same information twice, slowing down their reading of the page. | For this image from Encyclopedia SpongeBobia from above, the caption could read "SpongeBob starts singing, to Squidward's surprise." | |
|
|
For images of charts or graphs, provide a text alternative explaining the data. Users with visual impairments or those using screenreaders won't be able to get the data from the image alone. This data may also be too long for alt text. | For a graph displaying decreasing viewership, a paragraph or data table either before or after it should give the numbers and trends the graph shows. | |
|
|
For images containing text, explain what the text in the image is using alt text. Screenreaders won't read the text in the image as it's part of the file itself. | For this image of a watch from Encyclopedia SpongeBobia, alt text could read "Squidward's watch, with a pink strap, lavender background, and digital display reading 8:34." |
Design and color
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Ensure contrast of at least 4.5:1 between the text and wiki and template background. This ensures those with visual impairments or are standing in bright sunlight can read your content. |
|
Read more about color contrast |
|
|
Use a dedicated light and dark theme. This ensures readers can choose a theme that's most comfortable for them. | Light theme uses lighter colors for the background and content area, and text is is black by default. Dark theme uses darker colors, and text is white be default. | Read more about setting themes in Theme Designer |
|
|
Account for color-blind individuals when designing your wiki's theme and templates. Don't solely rely on color coding to relay important information as those readers may not understand parts of your content. | Instead of marking an admin as active using a green box, write the word "Active" inside it as well. That way you're not just relying on color. | Find out how to cater for color-blind readers on your wiki |
|
|
Ensure your wiki design is responsive to different screen sizes, and content area widths. FandomDesktop uses a responsive layout that changes with screen size. | Avoid locked table widths as tables won't stretch when you expand the content area. This could create a confusing experience for readers. | Read more about FandomDesktop and its responsive display |
Format
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Ensure your local wiki navigation is kept up to date and intuitive. Readers should be able to find what they want quickly, and confusing navigation may cause frustration when navigating your wiki. | Place content for new releases in the local navigation. That content is often most popular. | Read more about local navigation |
|
|
Follow a clear heading structure. This is important for screenreader users especially, who often use heading structures to navigate a page. | Screenreaders can navigate a page by header type. If a page uses Heading 3s where it should be using Heading 2s, those readers may be missing important context as they can't see the surrounding content. | Read more about formatting headings accessibly |
|
|
Format lists appropriately, such as using numbers or bullet points. These provide readers with important context to understand the aim of the list more easily. | A numbered list immediately indicates a reader could be looking at instructions, or a ranking of some kind. | Read more about formatting lists |
|
|
Use text styles in an intuitive way to distinguish text. This makes reading a page easier, as certain parts are emphasised to give it extra importance. | Underlining text should not be used, unless it is for links, as someone may get normal text and a link confused. | Read more about text styles |
|
|
Ensure link text tells the reader where they are going when they click a link. Without that, the reader has no context and clicks a link that may not go where they want it to. | "For more information on accessibility, click here" does not provide enough context. Where is "here"? Instead, the link should read "View more information on accessibility." | Read more about accessible link text |
Templates and coding
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Add documentation to all templates. This means editors understand what the template does, and how to use it. This documentation should be clear and give examples, to make the experience as easy as possible for editors. | See Avatar Wiki's Notice template. This includes detail on what the template does, syntax when using it, and example output. | Read more about template documentation |
|
|
Use easily readable source code in main namespace. Many editors may want to change a typo but do not know where to find it if the page is dense with unneeded source code. | Instead of pasting in source code for heading styling, make it a template instead. Rather than <div style="border:3px solid black; color:white; padding:2px...</div>, you can have {{Heading|Test}}.
|
Read more about coding and templates |
|
|
Use fonts and colors that are easy to read in templates. Not only does this help those with visual impairments, but also people to read your content faster in general, without needing to interpret a font. | Signatures are sometimes heavily customised, adding a lot of color and font changes. They can be hard to read. |
Tables
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Don't use empty cells. Screenreaders may struggle to interpret what's in them, and users may lose where they are in the table. | Use "Blank" or "Not applicable" in empty cells where possible. | Read more about table accessibility |
|
|
Use formatted header rows. This allows screenreaders to identify headings to read out, and helps those users navigate tables more easily. | Use ! Test heading with the exclamation mark instead of | Test heading with the pipe.
| |
|
|
When color coding tables, follow accessible color use and don't rely just on color. This is so colorblind users or those with visual impairments can interpret a table, not needing color. | Instead of having squares with green meaning "Win" and red meaning "Lose", actually include "Win" and "Lose" in those squares too. |
Language
| Achieved | Criteria | Example | Resources |
|---|---|---|---|
|
|
Language on a wiki should be easy to understand, with jargon explained, or kept to a minimum. Wikis have a very diverse audience and ensuring your content can be understood makes the experience better for the reader, and means they're more likely to return to your wiki. | Card pages like Swap Frog on the Yu-Gi-Oh! Wiki link off to other pages that explain terms relating to that trading card game. | Read the WCAG guidance on readable content |
|
|
Ensure your wiki policies are easy to understand and follow for community members. This will help users follow wiki policies and keep things running more smoothly. | Try to use bullet points and clear language to convey key information. | Read more about writing clear policies for your wiki |