Common Components
There are three styles of buttons: Primary, Secondary and Tertiary. Each has a different visual styling, but is also used for different purposes.
Primary buttons are used for the main action you want your visitor to perform.
Secondary buttons: Your page may or may not have a secondary action. When the choice of two actions is relatively equal, the primary and secondary buttons are used.
Tertiary button: If you need to provide another option, but it’s used less often, the tertiary button is used.The tertiary button often looks similar to a link, but functions as a button. For example, “Log on” may be the primary action, but “Forgot Password” may sometimes be needed during log on scenarios, but you don’t want to draw as much attention to it so it appears as a link near the primary button.
Every button on a page should be unique. Text for button labels should be short and descriptive, following WCAG guidelines – for example, instead of simply “Learn more”, or “Read more”, say “About Online Learning”, “Where to find us”, etc. This is particularly important when there is more than one button on a page, as screen reader users often tab directly through calls to action and won’t have the context for the button.
Writing button content:
Avoid duplicate labels on the same page.
Lead with a verb. What action does the user need to fulfill? Register for event, Download brochure, etc.
Use sentence case for buttons (Upper case first letter only)
Where links take a user somewhere, buttons generally do things. Make sure the button’s text makes clear to the user what is going to happen. Buttons tend to have less room for words than links, but similar rules apply:
Be as specific as possible, and avoid generic wording and filler words e.g. “Learn more” is too generic, but “Learn more about types of advocacy” may be too long. Shorter but still clear and specific: “Types of Advocacy” or even “Advocacy” will still be clear to the user.
Note: When it’s really not possible to be specific and unique in the allowable layout, ARIA (Accessible Rich Internet Applications) labels needs to be added to the back-end of the content for screen readers. ARIA labels will override the on-screen label with a longer description. This should only be used in extreme cases, as it’s possible some screen reader/browser combinations won’t read the added text.
Links
All links should be unique and descriptive, and let the reader know where they’ll be going when they select the link e.g. “More about our latest award winners”, not “Learn more”.
Never use “click here”: This language is outdated, and is considered an accessibility faux pas. It implies both visual ability (to understand where “here” is), and assumes the use of a mouse to navigate.
In-line links: When possible, put in-line links at the end of the sentence to make them more easily actionable by keyboard-only users. Example: “For more information about available workshops and registration deadlines, visit Professional Development.” A screen reader user gets the full context of the sentence, and doesn’t have to go back and hunt for the link.
Links to assets (PDF, Word, Video, etc.): Always identify the asset type in the link copy for any non-html content (an accessibility requirement).
PDFs should also include the file size in the link. For example, Donations Fact Sheet PDF (27 KB). Also include a PDF icon next to the link for visual identification.
Video links should identify the approximate run time in the link. This information helps a user determine if they should open the file (e.g. if on a mobile device, they may want to wait until they are on a larger device). See additional notes about video accessibility later in this article.
Links to third-party sites: When linking out to a third-party site, link as high as possible in the destination site, such as the site’s home page. Linking deeper, although more specific, runs the risk of broken links, because you can’t control another site’s content or changes they might make. Provide enough description in your copy to enable your reader to find what they’re looking through a quick search from the 3rd party home page. External links also have dedicated icons to let the user know that they’re leaving your site.
Static calls to action
Calls-to-action (CTAs) can take other forms beyond buttons and links. For example, static text may direct a reader to call a phone number or perform some other action.
As with links, word order is important for accessibility, especially for blind users who are listening to the text and relying on memory. Use the word order “to do (x), do (y)” e.g. “To register for the workshop, call 1-800-555-1234”. In this example, since the phone number is at the end, it’s easier for the listener to memorize if needed.
Videos
Videos have a number of mandatory accessibility requirements. Some of these will be under the control of the content editor.
Descriptive title: Embedded videos should include a descriptive title with an h-tag –e.g. generally H2 or H3, depending on its place in the content hierarchy; it won’t be H1, since that is reserved for the page the video is embedded in.
Descriptive transcript: Videos need a descriptive transcript to be ADA compliant. A descriptive transcript is a text version of all sound and voice content, plus
descriptions of any important visuals that convey information. Note that transcripts are often used by people who don’t necessarily need them for accessibility, such as when they have low-bandwidth, are in noisy environments, or need to skim content more quickly. The transcript should have a descriptive H1 that includes keywords. For more detailed information about transcripts and how to create them, see the Web Accessibility Initiative's article on Transcripts and Google’s Tips on Creating a Transcript File.
A link to the transcript should be on the page in which the video is embedded, outside the video frame so it can be accessed without opening the video itself. The link should just say “Transcript” (not “Read transcript” or “View transcript”.)
Closed captioning is required for deaf and hard of hearing users. It’s also useful for noisy environments, and helpful for people who speak English as a second language. Closed captions can be turned on and off. They differ from “open captions” which are on-screen, part of the image design, and are always visible. More information about captions can be found on the Web Accessibility Initiatives’ page on captions.
Accessible controls: the video should be able to be controlled with a keyboard only.
Never set to auto-play
Links to the video should identify the format and run-time. For example, Virtual visits how-to video (2:55).
PDFs
PDFs need to conform to the same accessibility guidelines as html pages. This includes:
All text can be read by a screen reader
Descriptive headline, tagged as H1
Subheads tagged as H2, H3, etc.
Descriptive file name
Images with alt-text
Tables coded to read out cells with headers
Links to PDFs should clearly identify the document as a link, and include the general file size.
Older PDFs are flat images that can’t be read as screen readers. Often they were created because the technology at the time was limited for printing documents; this is no longer the case, as pages can be printed from html without losing their formatting. You may want to evaluate your PDFs to see if they still need to be in PDF format. Many can be turned into html pages, which are easier to update and make accessible.
It is possible to tag older PDFs to make them accessible, but the process can be time consuming and expensive. If you must convert older PDFs, it’s easier and faster to make the original document accessible (e.g. a Word document) and then re-save it in an accessible format.
