12 Website Accessibility Guidelines to Follow

Is your website accessible to everyone?

This is an important question for any organization to consider, but it’s even more an imperative for the public sector (for one thing, it’s the law). In the digital era, the first place people turn for information from government is often the department or agency’s website. An office building without a ramp denies those who are mobility impaired access to the services inside; a website that doesn’t follow accessibility guidelines is the digital equivalent of that.

But making a website accessible is sometimes easier said than done, especially if you don’t have a point of reference. That’s why we’ve compiled a list of basic guidelines for accessibility best practices based on WCAG 2.1 AA standards. This is not a be-all, end-all list, but you can use these as a gut check on the current state of your government website.

Here are 12 questions to ask about the design of your government website:

• Does it have clarity to ensure it’s easy for user to see content? This includes sufficient contrast and not relying on color alone as a distinguishing visual element.
• Is it navigable for people with disabilities? This means using a proper heading structure and/or identifiable page regions that accessibility devices employ to assist the user. It should also be visually apparent which page element has the current keyboard focus when tabbing through the page.
• Does it avoid causing physical reactions? Flashing content can cause seizures or other physical reactions. So page content should not flash more than three times per second.
• Is all multimedia accessible? Audio descriptions should be available for all non-live video content for the visually impaired. Text-based descriptions should be available for all non-live video content for the hearing impaired. All live and non-live video content need to have synchronized captions.
• Is there a time limit to certain pages that may need to be altered? Automatically moving content that lasts longer than five seconds should include options to pause, stop, or hide it. Pages or applications with time limits should give users the option to turn them off, adjust, or extend them as necessary.
• Is it built to be keyboard and mobile accessible? All functionality on your site should be available using keyboard-only navigation. This includes not building in any keyboard shortcuts that interfere with browser or screen reader shortcuts. Website should also be built with mobile devices in mind—including the ways that navigation on them is different.
• Do all images have alternative text? Alt text is used by screen readers in place of images and that allow the content to be accessible. It should be a brief description of what the image is showing and also the function of that image (if it has one). And don’t skip decorative images – everything must have this included.
• Is it compatible with current and future assistive technology? Avoid HTML/XHTML validation/parsing errors, and use markup language in a way that facilitates accessibility. When HTML isn’t sufficient, use ARIA (Accessible Rich Internet Applications) to enhance accessibility.
• Is it adaptable to different presentation structures without losing information in the process? All information should be accessible in a form that can be determined by software – this way it can be spoken aloud or presented in a simpler layout for the user.
• Is text readable and understandable for screen reading devices? Part of this is including an HTML language attribute that identifies the language of the page. If a certain portion of the page is in another language, that too must be noted in the HTML.
• Is it predictable in the way user inputs and interactions are handled? Avoid changing the order of navigation links on the website, and be sure to consistently identify elements that have the same functionality across several pages (for instance: a search box at the top of the site should always be labeled the same).
• Is input assistance available? When form elements require a specific format (for instance: asking for a date of birth in MM/DD/YYYY), instructions and/or an example should be included for the user. If the user inputs information in the wrong format, validation errors should be efficient, intuitive, and accessible.

There’s a lot that goes in to ensuring that government website design is accessible to all. It starts with having the right website solution: Our govAccess solution can help you reach your accessibility goals with custom, user-friendly design. Interested in learning more about how Granicus can help? Get in touch with us today.