Website Accessibility Guidelines
Making content accessible to all is a legal requirement. This includes people who may have:
- Impaired vision (blind, partially sighted, colour blind)
- Deafness or impaired hearing
- Motor difficulties (e.g. unable to use a mouse or keyboard)
- Cognitive impairments or learning difficulties
Please consider the following guidelines when editing the departmental website. This guidance is not definitive, but should give a good overview of the things most relevant to our editors.
Page Title
The "Title" field is displayed prominently at the top of the page and used in search results. Because it may appear without surrounding context, the title must be clear, descriptive, and meaningful on its own. For example, use "Combinatorics Group Members" instead of just "Members" to help all users, including those using screen readers or assistive technologies, understand the purpose of the page.
You don't need to include "Mathematical Institute" or "University of Oxford" - each page has our logo at the top, and "Mathematical Institute" is automatically added for search engines.
In the Menu link, you can use a shorter title that makes sense within its section - e.g. within the "Combinatorics Group" section, simply "Members" would be fine.
Content
Write Clearly
Everyone appreciates writing that gets to the point. Using plain and simple language helps readers - even highly educated ones - understand your message more easily and reduces the risk of confusion or misinterpretation.
Simple language also makes your ideas more accessible and inclusive. It allows readers from diverse backgrounds to engage with your work without having to struggle through unfamiliar words or complex sentence structures. This doesn’t mean dumbing down your ideas - it means presenting them in the most effective way possible.
If you are writing instructions, make sure they are in chronological order - users shouldn't have to read ahead. Put any warnings up front.
Ask someone else to proof-read your content - they may spot things you won't.
Headings
Content should be broken up with headings ("Heading 2" in the editor) and subheadings ("Heading 3") to create a hierarchy. Each heading/subheading should describe the content that appears in the section/subsection directly below it. This makes it easy to get an overview of the content and jump to the relevant section, especially for those using screen readers.
Do not use bold, italic or other text styles to create headings - they are not announced as headings by screen readers.
Do not use headings just to get a larger font - it will be announced by screen readers as if it were a heading, making the document hard to navigate. Font size should be consistent across the website.
There is rarely a need for Headings 4-6 - using too many heading levels can make the content more difficult to navigate, and may be an indication that you should split the page up into several subpages.
Highlight Important Points
Highlighting important points in bold can enhance accessibility and readability, especially for users with cognitive disabilities or attention disorders.
But use bold sparingly to avoid overwhelming the user. It is better to remove superfluous text instead.
Note that screen readers don't generally read bold or italicised text any differently than regular text, so don't rely on it to provide meaning.
Links
Make sure link text is unique and descriptive. It should be possible to determine the purpose of each link without reading the surrounding text. This lets screen reader users jump directly between the links, and helps sighted users to scan the page looking for them.
Do not use "click here" or "read more" as the link text. For example:
- "Click here to download the full report" should become just "Download the full report" (the "click here" is redundant)
- "Learn more about the experiment" (only "Learn more" is linked) can become "Learn more about the experiment" (all part of the link)
It is best for links with the same destination to have the same text throughout the page.
Links with different destinations should always have different text.
Lists
Use either Bulleted List or Numbered List in the editor for anything that could be considered a list. This makes it easier for sighted users to see the items in the list are related, and for screen reader users to navigate through the list using keyboard shortcuts.
Do not simply type asterisks (*
), dashes (-
) or other symbols to make a list - screen readers can't understand them.
Tables
Tables should be used for tabular data (columns and rows). Do not try to line content up with spaces or tabs - screen readers can't understand that, and the layout usually breaks on mobile devices.
Apply the "Table: Standard" or "Table: Striped" style to make them visually appealing, then click the first cell and enable "Header row" or "Header column" as appropriate. This applies both the visual styles and the correct markup for screen readers to understand the table structure.
Set a table caption if possible - this is like a subheading that's specific to the table, and makes it easier for screen reader users to jump to the information they are interested in.
Do not use tables for visual styling or layout (e.g. to create two columns) - that is neither accessible nor mobile-friendly. Use the website's Layout options instead.
Images
Alternative Text
Alt text provides a hidden text description of an image which is picked up by screen readers (text-to-speech or Braille).
The alt text may vary depending on the context - for example, "a dog" or "a golden retriever lies on a green lawn, looking up at the camera, with its tongue hanging out and a tennis ball between its paws" would both be valid. Imagine you were reading the page aloud to someone - is it helpful to describe it in detail, or do they just need a short summary?
For a chart or graph, describe the key points - for example:
A scatter plot of 10 data points with a fitted linear regression line: y = 2x + 1. The points are tightly clustered around the line, indicating a strong positive correlation. Axes are labelled “input” (x) and “output” (y).
For a profile photo, try to paint a picture in a sentence or two - for example:
Amina Hassan - a Pakistani woman in her early 30s wearing a patterned hijab and a black blazer. She is smiling warmly, and the background shows a blurred library with bookshelves.
Do not include "Image of" or "Photo of" in the alt text - screen readers will say it's an image, so that is redundant.
If the image is just for visual decoration, or you would simply be repeating nearby text, alt text may actually be unhelpful. In this case, select "Decorative image" to tell screen readers to skip it.
Image Captions
Captions are visibly displayed below an image (unlike alt text). They are often used to provide supplementary information such as photo location or photographer/copyright information.
For neurodivergent users, captions can also be used to clarify social cues, emotions, or abstract concepts depicted in images that might otherwise be difficult to interpret. This also benefits users with cognitive disabilities by reinforcing the message through multiple modalities.
Text Within Images
Do not put a lot of text within an image - it goes blurry when you zoom in, can't adapt for small phone screens, and long alt text isn't always handled well by screen readers.
Text over the top of an image can be difficult to read, so prefer using a solid background colour (or a slightly translucent one) behind any text.
Colour
Don't rely on colour alone to express meaning, as many people are colour blind. (But you can use colour to augment information that is labelled or differentiated in other ways.)
Highly contrasting colours are easier for users with low vision to see.
Video / Audio
Make sure you include captions (video) or a transcript (audio). If they are auto-generated, check they are accurate.
If videos contain important visual information, they should also have an audio description. This would ideally be in the original audio (perhaps described by the presenter), but could also be available as an alternative "audio described" option.
If possible, also create an alternative (text-based) version of the content, or a summary that viewers can refer to for the key points. This is also a good place to include links to anything referenced in the video.
PDF Files
PDFs can present problems for screen readers, and they are not mobile-friendly, so prefer publishing information on web pages wherever possible.
If you do need to create a PDF, many of the guidelines above apply - use proper headings, lists and tables; use descriptive link text; include alternative text for images. Then make sure you use the software's "Save as PDF" option, rather than printing to PDF, to ensure that information is retained. See the University guidance on creating accessible documents for further details.
If possible, also make the original version (e.g. Word document) available, as that may be more accessible for some people. If you can't, at least make it clear who to contact to request an alternative format.
Webforms
Keep forms as short and simple as possible - don't ask unnecessary questions.
If the form is necessarily long or complex, group related fields using Fieldsets, or break it down into multiple pages. Use conditional logic to only show the questions that are relevant. Consider showing a preview before the final submission so users can double-check their answers.
Make your field labels as clear as possible. If necessary, use the Description field to provide additional information or explanation - but don't go overboard.
Use checkboxes only when multiple options may be selected. If only one option may be selected, use radio buttons for short lists of options (so all options are immediately visible), or Select dropdown lists for longer lists. Include "Not applicable" and/or "Other" options as appropriate.
Give a clear confirmation message after submission, to reassure the user it was successful.
Further Reading
- Accessibility training and resources from the university's Digital Communications and Digital Accessibility teams.
- Understanding accessibility requirements for public sector bodies - guidance from the UK Government Digital Service (GDS).
- How to write good alt text - a blog post by the Government Communication Service (GCS) Design Centre.
- Why GOV.UK content should be published in HTML and not PDF discusses some of the downsides of using PDFs.
On the wider topic of accessibility and inclusion across the university:
- Digital accessibility guidance from the university's Digital Communications and Digital Accessibility teams.
- Accessible and inclusive teaching from the university's Centre for Teaching and Learning.
- Inclusive Teaching Special Interest Group (SIG) on Microsoft Teams.
- The Disability Lectures - an annual lecture series that aims to increase understanding of the experiences of people living with a disability.
Contact Details
If you have any questions about the above, please contact the Maths IT Support team in the first instance.
For more detailed questions about accessibility, you may prefer to contact the university's Digital Accessibility Team.