Top Ten Guidelines for Accessibility on Your Website

1. Select an accessible content management system.

To assist you in building your website, there are numerous content management systems available. However, there are a variety of alternative possibilities as well. Common examples are Drupal and WordPress.

When a CMS that meets your needs has been selected, be careful to pick an accessible theme or design. For accessibility-related advice and pointers on producing content and layouts that are accessible for that theme, refer to the theme’s documentation. When picking out widgets, plugins, or modules, be sure to adhere to the same rules.

Make sure that components like editing toolbars and video players allow the creation of accessible content. For instance, the editing toolbars should have options for accessible tables and headings, and the closed captioning feature for video players should be available.

2. Organize your content’s structure with headings by using them correctly.

Heading structure can be used to browse material by screen reader users. Your website’s content will be properly arranged and simple for screen readers to understand if headings (h1>, h2>, etc.) are used effectively and strategically.

To separate presentation from structure, use CSS to follow the proper heading sequence (Cascading Style Sheets). Use a new CSS class to style your text rather of choosing a header solely based on how it appears on the screen (which may confuse users of screen readers).

Examples of headings that are used properly are:

• The page’s headline should be in h1> format. Except for the website title and the titles of individual pages, don’t use a “h1” tag for anything else.
• The structure of your content can be indicated and organized with headings.
• Avoid moving up or down in the heading hierarchy (for example, from a h1 to a h3) since screen reader users might think there isn’t any text.

3. Add appropriate alt text to all of your image files.

Screen reader users should be able to understand the message that is being sent by the use of images on the page if alt text is provided for the images. For informational visuals, this is especially crucial (such as infographics). If a picture already has text in it, that text should be included in the alt text as well. When writing the alt text, the wording should describe the message you want to express through that image.

If there is simply an image in a link, the screen reader will read the file name if no alt text is present. Images that are used as links should always include alt text.

4. Make sure the names of your links are original and informative.

When incorporating links in your material, make sure the wording accurately indicates where the link will take the user. “Click here” is unhelpful for screen reader users and is not regarded as descriptive language.

Given that screen reader users frequently scan the links list by the initial letter, the link’s most distinctive content should be displayed first.

As an illustration, suppose you are directing site visitors to a page titled “About Us”:

• Make an effort to avoid saying, “Click here to read about our company.”
• Stating “Read About Us to discover more about our organization” in its place

5. Use color sparingly,

Approximately 8% of people suffer with red-green color deficiency, the most prevalent type. These people won’t grasp your message if you only use these colors (particularly to denote required fields in a form).

When utilized to distinguish and arrange your content, color has significant advantages for other disability-related groups, notably users with learning difficulties.

6. Designing shapes with accessibility in mind

The screen reader user does not have the same indications at their disposal as the sighted user when form fields are not labeled correctly. You might not be able to tell what kind of information should be entered into a form area.

Take into account using fieldsets to assemble related or comparable fields. The category “Personal Information” could have fields like “Full Name” and “Date of Birth,” for instance. By providing the context that can be missed while filling out the form, this sort of form organization might assist a screen reader user in keeping track of their progress.

If a form field has to be filled out, it needs to be identified as such and set up to notify screen reader users when it is needed. Asterisks, which some screen readers can not speak, are frequently used to indicate that a field is necessary. Asterisks (or comparable visual cues) should still be utilized for blind users, those with learning difficulties, and those who speak English as a second language. By adding ARIA required=”true” for mandatory fields and ARIA required=”false” for optional fields, you may tell a screen reader if a field is needed or not. The user must be informed after submitting the form whether it was received and whether there were any mistakes. Once the user has submitted the form, we advise include any mistake numbers in the page title so they are obvious to the user. If a user submits a form with mistakes, the user ought to be directed to a submission page that details the errors and offers a simple path to them.

Last but not least, CAPTCHA is difficult to use and is not a good option for submission validation. To prevent form submissions from spam, WebAIM has a handy list of accessible alternatives to CAPTCHA (link is external).

7. Use tables for tabular data, not for layout,

Screen reader users experience more verbosity when using tables for page layout. When a screen reader comes across a table, it alerts the user that there is a table with “x” number of rows and columns, which detracts from the text. It’s also possible that the reader will read the contents out of sequence from how they see them on the page. Use CSS for presentation, not a table, to build a website’s layout.

8. Make sure all content is logically accessible using only the keyboard.

It’s possible that those with mobility issues, such as those who have sustained repeated stress injuries, won’t be able to operate a mouse or trackpad. By pushing the “tab” or “arrow” keys on a keyboard, or by using other input methods such a tongue stick or a single switch, these users can access content. To enable keyboard-only visitors to logically navigate through the site’s information, the tab order should therefore correspond to the visual order. Long pages with a lot of content should be divided up with anchor links (jump lists), enabling keyboard-only users to skip to relevant sections of the page without having to wade through other content.

9. Use landmarks and roles from ARIA (but only when necessary).

ARIA (Accessible Rich Internet Applications) is a sophisticated, potent technical standard for incorporating accessibility information into aspects that aren’t already inherently accessible. When native HTML components are offered, you ought to always use them. The first rule of ARIA is to never use it, so keep that in mind. Many HTML5 features that once required ARIA attributes are now supported by the standard.

Examples include:

• Replace the ARIA role of button with the standard HTML button tag.
• Avoid using aria-label or arial-labeledby in favor of the HTML label tag.
• Replace the ARIA role of navigation with the HTML 5 nav tag.

The same way that you add classes to HTML to enable the loading of CSS attributes, ARIA attributes can be introduced to your HTML.

The majority of sophisticated widgets cannot be made accessible by just adding ARIA attributes, therefore take note of this. Solely users of assistive technology are impacted by ARIA; users who only use their keyboard are unaffected (see tip #8). Still, you need to use Javascript to build up your communications and actions.

The following are examples of proper ARIA usage:

• Adding alerts to inform screenreader users when dynamic page changes, like stock tickers and search filters, take place
• accessibility for screenreader users of intricate, interactive widgets like date pickers.

10. Make available dynamic material

Screen readers might not be informed when material is updated dynamically (i.e., without reloading the page). In-page updates, popups, lightboxes, screen overlays, and modal dialogs are all examples of this. Users who only use a keyboard risk getting stuck in page overlays. Users with magnifying software can be focusing on the incorrect part of the page when using their software.

The accessibility of these features is simple. There are front-end development frameworks that expressly enable accessibility as well as ARIA roles and alerts as alternatives.

Make sure that any video players you employ can be operated with a keyboard and that they don’t auto-play (with incongruous sound). Furthermore, every video must offer the option of closed captioning and transcripts for hard of hearing viewers.

Markustudio a freelance web designer in Manchester providing web design, logo branding, print, SEO and digital design services. If you are interested in any help when it comes Web Design & Development. Feel free to Contact Us.