Web accessibility is making sure that our website can be used by people with disabilities. Creating accessible content breaks down barriers and leads to more seamless access to information which leads to less need for accommodations. The principles for creating accessible content are outlined below.
The clickable text of a link MUST be descriptive. If you can't tell where you will go when you click on a link by looking at the text alone, your link isn't accessible.
Links that have just the words “click here” or "see more" as the text create problems for our patrons who use screen readers to navigate our site. Typically, they use the tab key to jump from link to link as their version of skimming the page. When links are labeled vaguely or in a way that requires the user to see the context around it to make sense of the link, it makes that content inaccessible. 
Wrong:
Click here to read more about website accessibility.
Right:
Read more about website accessibility.
When adding links in LibGuides, whenever possible do not add them in the rich text/HTML but rather as link assets and provide a descriptive link name.
Images must have an alt (alternative text) attribute describing the image. The alt attribute provides alternative information for an image if for some reason a user cannot view it (because of a slow connection, an error in the source code, or if the user uses a screen reader). Image alt text must not be the same as the image file name.
Table elements on web pages are great tools for sharing data, but the worst tool for layout and positioning. They should never be used to align text and images for visual layout purposes.
Tables should be set up to help screen readers identify key elements. A table header identifies the column headings and a caption functions as the table title.
When working on tables in Rich Text/HTML editor:
| Name | Age | Birthday |
|---|---|---|
| Cordelia | 5 | January 4 |
| Goneril | 8 | April 15 |
| Regan | 11 | December 3 |
Web content should be properly structured using heading elements. Headings (H1, H2, H3, H4, H5, and H6) create a navigable table of contents for people using assistive technology.
Most web templates also format headings in such a way that using them also creates a visual hierarchy that helps all users quickly scan and find the content they are looking for. Using headings solely for their visual treatment without taking into account the structural purpose they serve is very bad for accessibility (and findability!) and should be avoided.
Links to PDFs need to include "PDF" inside the link so that people using screen readers know that they are about to open a PDF.
All Word, PowerPoint, and Excel files should be saved as PDFs and then tested for accessibility before being uploaded.
Don't copy text from Word or other applications directly into the rich text field. It adds all kinds of bad code. Copy it first into TextEdit (Mac) or Notepad (PC) to remove superfluous formatting.
Don't use centered or justified text. Left-aligned text is considered best practice for text readability.
Don't make things that aren't lists into bulleted lists. The "bullet list" tool isn't for adding emphasis; it's for creating a list of items.
Don't overuse bold and italic.
Don't use punctuation and formatting for "design." What might look good on one size of screen can look very different on another; it’s best to let the content flow on its own. Examples:
Acronyms and abbreviations can be problematic for screen readers because they try to read them as words. Here's how to make them more clear:
The distinction between these is that the acronym is usually pronounced as its own word, whereas the abbreviation is pronounced by saying each letter.
Phrases in a different language need to be identified with a LANG attribute which can be added to a tag surrounding the bit of text.
| Language | Code |
|---|---|
| Italian | it |
| Spanish | es |
| German | de |
| French | fr |