Designing a clear, predictable layout for your information, that is designed to be easily navigated with assistive technologies, is a critical aspect of accessibility. However, designing for clarity with clear and descriptive content helps everyone to easily scan and find the information they need.
Hyperlinks: be descriptive
Hyperlinks allow for navigation both internally to visit relevant other pages in a website, or externally to a service or product that is being described on the page.
Visual consideration:
While recent practice has been to simply use a bright colour to indicate a hyperlink, this does not help those who have low vision navigate easily. Best practice is to not rely on colour alone, but also make the linked text bold, which has high visibility. Using an underline for hyperlinks is still a good option.
Also, don’t underline text that isn’t a link!
Descriptive language best practices:
Hyperlinks provide users with a shortcut to more information, either internally within the website itself or to an external website. Informative hyperlinks let people know where the link will take them. Assistive technologies help people navigate these links. For instance, screen readers identify links and then read the linked text. Vague links such as “read more” or “click here” are not helpful or informative.
What to check:
- Eliminate all instances of Click here or Read more or Learn more or Visit this page – transcribe the title of the page where the link is taking the user so that they know what is to be expected (this helps with cognitive expectations).
- Note! When creating a slide, you may want to tell the visitor that the slide is clickable, so using Click here or Click this slide is actually ok. When creating your Alt Text – make sure that you indicate that clicking goes to a page
- Do not use the full URL of the page to which you are linking, as a screen reader will try to read the actual text of https://accessiblelibraries.ca.
- Emails and Telephone numbers: use <a href> tags to hyperlink emails mailto:email@email.com> and even telephone numbers (“tel:250-111-2233”) help with dialing.
- It may be helpful to indicate when a link is external, and that they will open into a new tab. In the Page Edit view, right-click on the link and select the pencil icon to edit. Then click on the gear icon, and check the box that says “Open link in a new tab” then save.
- If linking to a PDF, indicate this by inserting “(PDF)” at the end of the hypertext.
Emails and Telephone numbers: use <a href> tags to hyperlink emails “mailto:email@email.com”>and even telephone numbers (“tel:250-111-2233”)to help with dialing.
Headings: clear and concise
Web pages often have sections of information separated by visual headings. That way people can navigate to the headings — including people who cannot use a mouse and use only the keyboard, and people who use a screen reader or other assistive technologies such as switches or voice controls. Help the reader to understand how the content is formatted, using a “predictable” hierarchy. Realize that this also helps someone with comprehension or literacy difficulties, as the headers should reflect a clear idea of what the content is about, and stated in plain language.
Heading levels should have a meaningful “rule of hierarchy.” These should be continuous, and not jump from an h2 to a h4. Here is an example heading structure in the correct nesting order:
Heading Level 1 <h1> – note that in LibPress, this is the tilte of the page. There should only be one H1 per page so your content will next use…
- Heading Level 2 <h2>
- Heading Level 3 <h3>
- Heading Level 3 <h3>
- Heading Level 2 <h2>
- Heading Level 3 <h3>
- Heading Level 4 <h4>
- Heading Level 4 <h4>
- Heading Level 3 <h3>
- Heading Level 2 <h2>
Do not confuse the visual look of a header with markup code. Apply formatting of different font weights or size to a header, but the nesting hierarchy code is necessary for assistive technology to function.
What to check for:
- Headers are “nested” appropriately.
- Try not to use more than three levels of headers. Instead, consider rewriting and reorganizing the information on your page.
Note also that web crawlers go first to headers and so making these as descriptive as possible using key words will help your search engine optimization as well.
Page Titles: unique and descriptive
Good page titles are particularly important for orientation: helping someone understand where they are, how they got there (from a clearly labelled or descriptive link), and what they will find on that page. The first thing screen readers say when the user goes to a different web page is the page title. Page titles also appear in the browser tabs, so the user can move between pages open in their browser.
What to check for:
- The title should adequately and briefly describe the content of the page so that the reader immediately understands what the page will be about.
- Check that the title is different from other page titles on the same website, and adequately distinguishes the page from other web pages.
- Best practice is for titles to be “front-loaded” with the important and unique identifying information first. For example: use About your Library instead of Your Library – About.
- The page title should be the first header (H1) in the page. Best practice is that there is only one H1 in the whole page, so that the next header would be a H2. More in next section.
Paragraphs: don’t indent first line
When using LibPress, paragraphs will automatically have an extra space in between for easier visual reading. Do not indent the first line!
Lists: choose the correct form
Correctly formatted lists are important for all users, especially those with print disabilities. Lists organize the information and are read as a list of items rather than in paragraph form, making content easier to comprehend.
Use the proper code for the type of information in the list:
- Unordered lists <ul> are for related information that do not have an order inherent to their understanding.
- Ordered lists <ol> are for procedures that need to be followed in a certain order.
See HTML Lists (W3Schools) for more information.
Tables: avoid using them!
A table should only be used for tabular data (e.g., data that can be understood in a table format). Tables should not be used for page layouts (e.g., agendas or schedules). For these, you should use headings and lists.
Tips for creating accessible tables:
- Always include clearly defined borders for all elements of the table (columns and rows).
- Always have a header row: The first row of the table should state what kind of information is contained in each column (rows go across and columns go down). This provides context for the data and assists screen readers in navigating the table.
- Use a simple table structure: Avoid tables nested within other tables. Also, avoid merged or split cells. All of these will make it difficult, if not impossible, for screen readers to read the information in the table aloud in a way that makes sense.
- Add alt text to the table: It can be time-consuming to read a table with a screen reader. Use alt text to add a brief summary of the information provided in the table so that screen reader users can decide if they want to read the table in its entirety
- Include a caption and title for your table to provide more information and explain what the table is for.
- Avoid blank cells: You should never leave the left uppermost cell blank, as it is the first cell a screen reader user will encounter. Blank cells anywhere in the table could also mislead someone using a screen reader into thinking that there is nothing more in the table. Cells without data can be filled with a dash (-) or N/A.
- Do not leave blank rows or columns in your table. If you want to visually differentiate your rows and columns in your table, adjust the line spacing/design instead.
- Do not use screenshots of tables: Build a table in your document or website properly. A screen reader cannot read an image, so a person using a screen reader will not know what data is contained in a screenshot of a table.
Still want to use a table on your page? Follow the directions for correct code and markup at Tables with One Header (W3C).