Contents
2.1 Provide informative, unique page titles
2.2 Give the document a structure
2.5 Write meaningful text alternatives for images
2.6 Create transcripts and captions for multimedia
2.7 Keep content clear and concise
3.1 Writing accessible documents
3.2 Provide clear instructions for interaction
3.4 Keep the document structure simple
3.5 Forms, complex documents and other office formats
3.6 Making non-HTML documents accessible
5 Additional information and accessibility tools
5.2 Accessibility testing tool
5.3 Resources to help evaluate web accessibility
5.4 How to Meet WCAG (Quick Reference)
1. Document Purpose
1.1 Summary
User guidelines documentation for the QURIS system March 2021 onwards.
2. Accessible web content
2.1 Provide informative, unique page titles
For each web page, provide a short title that describes the page content and distinguishes it from other pages. The page title is often the same as the main heading of the page. Put the unique and most relevant information first; for example, put the name of the page before the name of the organization. For pages that are part of a multi-step process, include the current step in the page title.
- Home page title
- Space Teddy Inc.
- Page name followed by organization name
- Latest News • Space Teddy Inc.
- Page name including step in a process
- Buy Your Bear (Step 1 of 3) • Space Teddy Inc.
2.2 Give the document a structure
- Break up your document to make it more readable. Use bullet points, numbered steps and meaningful subheadings.
- Use headings to convey meaning and structure. Use short headings to group related paragraphs and clearly describe the sections. Good headings provide an outline of the content.
- Do not use bold to mark-up subheadings. Use styles to create a hierarchy of headings: ‘heading 1’, ‘heading 2’ and so on.
- Use styles for tables and bullet lists. That way, a screen reader will recognise the formatting and read out the content correctly.
2.3 Keep the language simple
- Use clear and simple language.
- Simple language makes your document accessible to people with cognitive impairments and learning disabilities.
- Research shows that most users prefer simple language, including specialist audiences. This helps users to understand and process information quickly.
- Where you need to use technical terms, abbreviations, or acronyms, explain what they mean the first time you use them.
2.4 Make link text meaningful
Write link text so that it clearly describes the content of the link target. It should also be understandable on its own, even if read out of context. This is because some screen reader users list links on a page to find what they need quickly. Avoid using ambiguous link text, such as ‘click here’ or ‘read more’. Indicate relevant information about the link target, such as document type and size, for example, ‘Proposal Documents (RTF, 20MB)’.
- Link text (labelled link title in the CMS link picker):
- As touched on above, please ensure link text is succinct and relative to the action the link carries out.
- When adding links through rich text editors, please ensure to specify a sufficient title attribute for the related item. This provides additional context to the link item and ensures users with visual impairments can also utilise this information to aid them when navigating the site.
- It is best to avoid lengthy link titles to ensure they are readable and reasonable.
- Link target:
- When prompted to specify the target of a link, you will typically be given the option to let it open in a new tab/window, or let it open within the same window or tab as per the default functionality.
- When a link is to an internal page:
- Use the default option which is blank, with nothing selected.
- When a link is to an external page or site:
- Use the “opens the linked document in a new window or tab” option.
- If you set it to open in a new tab or window, then you must ensure the title attribute reflects this by adding the following to the title attribute:
- (This will open in a new window)
2.5 Write meaningful text alternatives for images
For every image, write alternative text that provides the information or function of the image. For purely decorative images, there is no need to write alternative text.
- Uninformative
- Medicine name.
- Informative
- A photo of medicine name being administered to a patient.
2.6 Create transcripts and captions for multimedia
For audio-only content, such a podcast, provide a transcript. For audio and visual content, such as training videos, also provide captions. Include in the transcripts and captions the spoken information and sounds that are important for understanding the content, for example, “the door squeaks”. For video transcripts, also include a description of the important visual content, for example ‘Nathan leaves the room’.
2.7 Keep content clear and concise
Use simple language and formatting, as appropriate for the context:
- Write in short, clear sentences and paragraphs.
- Avoid using unnecessarily complex words and phrases.
- Consider providing a glossary for terms readers may not know.
- Expand acronyms on first use. For example, Web Content Accessibility Guidelines (WCAG).
- Use list formatting as appropriate.
- Consider using images, illustrations, video, audio, and symbols to help clarify meaning.
3. Accessible PDFs
3.1 Writing accessible documents
Follow these steps when you write a document. If you have questions, contact your website publishing team.
3.2 Provide clear instructions for interaction
Ensure that instructions, guidance, and error messages are clear, easy to understand, and avoid unnecessarily technical language. Describe input requirements, such as date formats.
3.3 Think about formats
Doing this will help your document support as many users as possible and can future proof your information.
Publish in HTML format wherever possible so that your documents use your users’ custom browser settings. It can be difficult to make other formats easier to read. For example, PDF documents:
- can make your content harder to find, use and maintain
- do not work well with assistive technologies like screen readers a lot of the time
If your documents do not meet accessibility standards you could be breaking the Equality Act 2010.
3.4 Keep the document structure simple
- Give the document a meaningful title.
- Keep sentences and paragraphs short. Aim for around 25 words or less per sentence.
- Use a sans serif font like Arial or Helvetica. Use a minimum size of 12 points.
- Use sentence case. Avoid all caps text and italics.
- Make sure the text is left aligned, not justified.
- Avoid underlining, except for links.
- Avoid footnotes where possible. Provide explanations inline instead.
- Only use tables for data. Keep tables simple: avoid splitting or merging cells.
- Documents with single continuous columns of text are easier to make accessible than documents with a complex layout.
- Do not use things like colour or shape alone to show meaning. Instructions like ‘click the big green button’ rely on the user to see the page and someone who is colour blind may not see the green button.
- If you are using images or charts, think about how you’ll make the content accessible to people with a visual impairment. Two options are:
- Make the same point in the text of the document (so people with visual impairments get the information they need - the image or chart is there as an extra for people who can see it).
- Give the person converting or uploading the document the alt text (‘alternative text’) required for the image or chart.
- Do not use images containing text, as it is not possible to resize the text in the image and screen readers cannot read text which is part of an image.
3.5 Forms, complex documents and other office formats
- Build forms in HTML where possible.
- Publish forms in OpenDocument if you cannot use HTML.
If you are creating another type of office document (for example a spreadsheet or presentation), there’s guidance on how to make it accessible on the Accessible Digital Office Document Project website.
3.6 Making non-HTML documents accessible
Turn existing PDFs into:
- HTML if it is to be viewed.
- an OpenDocument if it is to be edited, such as a form.
If you need to keep the PDF, you must publish an accessible version with it. If you do not, you may be breaking the law.
It is simpler to create HTML from an OpenDocument or Word Document than it is to try to make a PDF accessible for all users.
4. Personalisation
The following fields have been added to the system to allow you to quickly and easily add a level of personalisation to your website.
4.1 Primary colour
Specify any HEX colour code of your choice and this will be applied to the following areas:
- Header: Background colour for component and subcomponents.
- Footer: Background colour for component.
- Scrollbar: Background colour for scrollbar track.
4.2 Secondary colour
Specify any HEX colour code of your choice and this will be applied to the following areas:
- Header: Colour for borders.
- Footer: Colour for borders.
- Scrollbar: Background colour for scrollbar thumb.
Please note that if either of the above are specified (primary or secondary colours), the search box button within the header automatically gets set to a darker colour.
4.3 Header and Footer links
Due to the nature of the colour picker, ensuring links are a colour that complies with the chosen colour of the header and footer can be done by toggling the checkbox in this section.
For example:
- Header and footer have been updated with a custom colour; the colour is quite dark.
- By default, all the text and links within the header and footer are white, therefore no action is required.
- Header and footer have been updated with a custom colour, the colour is quite bright and now the links are illegible.
- By toggling this option on, all text and links within the header and footer will be updated to be dark and provide a better contrast with the header and footer backgrounds.
5. Additional information and accessibility tools
5.1 Colour Contrast Checker
https://webaim.org/resources/contrastchecker/
5.2 Accessibility testing tool
5.3 Resources to help evaluate web accessibility
More information on evaluating accessibility from World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI)
https://www.w3.org/WAI/test-evaluate/
5.4 How to Meet WCAG (Quick Reference)
A customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2 requirements (success criteria) and techniques.
Comments
0 comments
Please sign in to leave a comment.