Type the code from the image
There’s currently a huge push to improve accessibility and make the web available and easy to use for everybody - for good reason too. Not only will you be making your website available to a broader scope of users but a lot of accessible design and development practices help make your website better to use for all users, not just those with disabilities. Plus, it’s the law. All new public websites, refreshed websites, and web content in Ontario must currently meet the Web Content Accessibility Guidelines (WCAG) 2.0 Level A guidelines (and by 2021, all public websites and web content posted after 2012 must meet Level AA). There’s a lot to gain by having an accessible website and nothing to lose!
With all this talk about accessibility in web development, you might be aware of some of the more well-known aspects of accessible websites. Things like keyboard accessibility, text alternatives for images, high-contrast and resizable text, and epilepsy-proof content might spring to mind when you think about making your website accessible. But what about some of the more obscure aspects of accessibility? Here are eight accessibility guidelines that might have flown under your radar.
Links to official WCAG documentation have been provided for all these guidelines. I highly recommend you check them out - consider my descriptions like a primer of sorts. You can access the links by clicking on the header for each guideline.
Error prevention on websites that enable users to make legal commitments or financial transactions might seem like general website functionality, but error prevention falls under the purview of accessibility as well. This is because errors on forms can disproportionately affect those with vision or motor impairment. However, this guideline helps all users effectively and confidently use the web. Sites that enable legal commitments or financial transactions must either: allow reversible submissions, data check errors and provide users the opportunity to correct them, or allow users to review and confirm information before submission.
Well designed websites typically outline a structure for their content and use visual cues to indicate the relationship between content (for instance, the use of bold headings or list items beginning with a bullet). An accessible website will make this structure and these relationships evident for all users, not just sighted ones. This can be done by using appropriate markup - for instance, a screen reader user will be able to perceive what is a list and what is not if using the appropriate <ul> (unordered list) or <ol> (ordered list) and <li> (list item) elements. If there is no associated markup to programmatically determine a certain type of information or a certain relationship of item, you should include a text description. You can see this often on sites with forms that let the user know “all required fields are marked with an asterisk”. Moreover, you can use ARIA attributes to help communicate more information to users in an accessible way. For instance, the ARIA attribute “role” helps to communicate the role of UI elements, where the ARIA attribute “properties” will describe characteristics about the element (for example, if it’s draggable).
Time based media like music, podcasts or videos should have alternative ways of accessing their content. Alternatives could be a text transcript of an audio recording or an audio description of a silent movie. The idea behind this accessibility guideline is that individuals with limited hearing, limited vision, or both can access the same content as everybody else. Guidelines differ depending on certain characteristics of your time-based media - for instance, whether the media is live or pre-recorded or whether the media uses captions or not (so be sure to check out the link).
While we’re talking about time based media, let’s chat about how else you can make this kind of media more accessible to a wider array of users. If your content contains any kind of time limit, you should consider that some users may need more time to interact with your it than others. Content with time limits should do at least one of the following: allow the users to turn off the time limit before encountering it, allow the user to adjust the time limit (to at least ten times the length of the default setting), or ensure that users are warned before the allocated time expires and are given at least 20 seconds to extend the time limit (and the user is allowed to extend the time limit at least ten times). Of course, there are exceptions to these guidelines: if the time-limit is a required part of a real-time event (for instance, an auction), if the time limit is an essential part of the activity and extending it would invalidate it (for instance, a quiz show), or if the time limit is more than 20 hours.
This is one of those guidelines that you may not consider when first thinking about accessibility, but its importance is pretty evident upon reading it. Instructions for consuming or manipulating content should not solely rely on sensory characteristics to provide adequate instructions. This means that instructions such as “press the round button on the right” need to be accompanied with additional information to remain accessible to all users (since not all users will be able to perceive shapes or position). This guideline is mean to supplement this information though, not replace it. For instance, a successful implementation of this guideline would have instructions which use positioning, color, and labelling to communicate with users - “to move to the next section of the survey, select the green arrow icon labeled ‘Next’ in the lower right corner below the last survey question”.
Content that moves, blinks, or auto-updates can provide challenges for all users, not just those with disabilities. This kind of content can often be distracting or difficult to read depending on its implementation. Moving, blinking, or scrolling information that starts automatically, lasts for more than five seconds, and is presented in parallel with other content should give users a mechanism to pause, stop, or hide it (except in cases where the movement, blinking, or scrolling is an essential part of the content). Auto-updating information should have a similar mechanism if the information auto-updates automatically and is presented in parallel with other content (except in cases where the auto-updating is an essential part of the content). It’s important to note that this guideline does not address seizures and epilepsy. Guidelines regarding seizures and epilepsy can be found at this link
In order to keep content accessible, text should be used to convey information rather than images of text. Not only is this useful for those with screen readers, but content is more easily consumable for all users since text can easily be resized, copied, and pasted. There are a couple exceptions where using images of text is appropriate. If a user can customize the image of the text, if the text is part of a picture that contains significant other visual content (like a diagram or a graph), or if a particular presentation of text is essential to the information being conveyed (like a logo or wordmark) - these are all considered appropriate circumstances to use an image of text rather than text.
Rest easy Admiral Ackbar, the WCAG has you covered. Those navigating through web pages using a keyboard interface need to be able to actually navigate through the entirety of the content. Often, websites are coded in such a way that content “traps” keyboard focus to within a certain subsection and makes it difficult or impossible for keyboard users to leave this subsection. Restricting focus to a subsection is fine, so long as users know how to leave this subsection without being “trapped”. Specifically, if the user requires more than unmodified arrow or tab key presses (or other standard exit methods), then the user must be advised of how to move focus away from a subsection. Generally speaking, if keyboard focus can be moved to a subsection of a page by way of a keyboard interface, then it should be able to move focus away from this subsection using only that same keyboard interface.
There you have it, eight WCAG 2.0 accessibility guidelines that you may not have known about! If you’d like to learn more about accessibility, you can check out the World Wide Web Consortium’s introduction to the Web Content Accessibility Guidelines. You can also read about the province of Ontario’s implementation of the WCAG guidlines here. Lastly, the World Wide Web Consortium also provides a list of accessibility tools at this link