Introduction

Here are several steps that can form the basis for an accessible site. Following these steps does not guarantee that the information will be accessible, however, it will greatly help. In addition to improving the accessibility of your information and services, following these steps will improve the findability, search engine ranking, and usability of your sites for all users.

To maximize accessibility, these steps should be applied with knowledge of WCAG 1 and 2 and best practices.

Consider using the Framework for development. The Framework is the language-agnostic ASP framework that CNS maintains for webmasters who want to use the new Common Look and Feel. We also provide documentation for the Framework; from building a simple site to using some extra features like the database or XML functions. Government employees can access the latest documentation and files here on the government webmaster intranet.

Basic Principles: POUR

To improve usability and accessibility we use the concept of POUR, which are the guiding principles in WCAG 2.0. As explained by the W3C, information and services must be:

• "P = Perceivable Information and user interface components must be perceivable to users in ways they can perceive.
• O = Operable User interface components must be operable.
• U = Understandable Information and the operation of user interface must be understandable by users.
• R = Robust Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies."

Basic Steps to Improve Accessibility

1. Use standards-compliant, semantic XHTML or HTML5 that validates. A number of alternative browsers used by people with disabilities have trouble with non-standard code, so make sure your code validates. Include a Document Type Declaration (DTD) unless using HTML5. Note that you have to do more than just refer to the DTD, you have to make sure your code validates (by, for example, checking it with the W3C online validator).
2. Separate content from presentation. Markup your content according to what it is, not how you want it to look. Put prose inside <p> tags, list items inside <li> tags, etc. In other words, use HTML semantically such that if something is in essence a list then tag it as a list, and if something is the most important header on the page, tag it as an <h1>. Use CSS to control the presentation of the content.
3. Use tables for tabular data, not for page layout. Putting non-tabular information into tables is not only semantically incorrect, but can also result in your information being inaccessible to users with alternative user agents (browsers). This is because these user agents (browsers) might render your tables out of order, which would mean that your information would be presented out of order, too. Tables should have appropriate table headers (the <th> element). Associating data cells with their headers will make it easier for screen reader users to navigate and understand the data table in proper order.
   • Table summaries can provide a quick idea of what the table is all about. Use the summary attribute for the <table> tag for complex tables.
   • Use the <thead> (table head) element to group rows that have just <th> (table header) cells. The remainder of the table can be grouped using the <tbody> (table body) element.
   • Table labels (th cells) can be designated as belonging to either a row or a column by using the scope attribute.
   • If your tables are very complex it is possible that the scope attribute might not be able to provide the proper information, and you would have to associate table labels (th cells) with individual cells by using headers and id attributes. This can take a lot of time with complex tables, and it might be easier to redesign the table or split it into more than one and use the scope attribute.
   • Provide abbreviations for table labels (th cells) by means of the abbr (abbreviation) attribute if the label is so long that it would be inconvenient to hear a speech browser read it over and over.
   See: Accessibility and tables.
4. Use a text equivalent for all non-text elements. Graphics can be of no use to those with various disabilities. Text descriptions of the elements can help to convey the information to these people. Make sure all images not used for decoration have a descriptive alt attribute. If the description cannot be contained in the alt attribute, use an extended description. E.g. the alt tag of an image containing an address should contain that same text, not the description "Our address". See: How to Provide Alternatives to Non Text Content on a Website.
5. Never use colour alone to convey information. People with various disabilities might not be able to perceive differences in colour alone. When using colours, make sure that there is sufficient contrast between elements (like backgrounds and foregrounds) so that people with low vision and/or colour blindness can distinguish between your elements. For example, do not use colour alone to indicate a hyperlink; use context (e.g. the page context of the link), surrounding information, or style (e.g. text-decoration: underline; , or leaving the default underlining of links on) to indicate hyperlinks. See: Visual Disabilities Color-blindness and Use of Color: Understanding SC 1.4.1.
6. Make content easy to read. Put your content though a plain language edit whenever possible. This will make your content much more understandable, especially for persons with cognitive disabilities. Use proper headings and lists to break up your text into logical sections. Give each page a good title. See: Writing Clearly and Simply.
7. Make sure all vital information is accessible and perceivable. Allow for differences in user agents (browsers). Make sure that essential features such as navigation and forms will work should Flash, images, scripts, or CSS be disabled or unavailable. Care must be taken to ensure that the widest possible audience can have equivalent access to Nova Scotia government experiences and services. Careful planning and testing on a variety of platforms and with different browsers is essential. Make sure that the W3C DOM is used according to specification. Ensure that JavaScript event handlers are device independent (e.g., they do not require the use of a mouse). Remember, :hover will only work for a mouse. Use both :hover and :focus like in this example: a:hover, a:focus {your css;}. Make sure the functioning of your page is not JavaScript dependent. For example, do not use JavaScript to create drop down menus as this makes access to the links impossible for screen readers and anyone who navigates with a keyboard. Rather, use CSS and/or lists to create clear and consistent navigation. There are many excellent examples of how to use scripting (including AJAX) with ARIA to make sure your scripts and widgets are usable to as wide an audience as possible. See OpenAjax Examples.
8. Make sure that all forms can be completed and submitted by users. All form elements must have a label associated with it (using the <label> tag). Check the behaviour of your forms including how they handle errors to make sure that all users have clear instructions on how to correct any errors (such as not filling in all fields). Make sure your forms can be found, navigated, filled out, and submitted by screen readers users and people not using a mouse. CNS can help with testing of this and any other part of these Basic Steps, See: Creating Accessible Forms.
9. Provide a way for users to skip repetitive elements. Use skip links to help users bypass repetitive elements (such as navigation menus and other elements that appear on every page). Make sure the skip links are prominent—they should be located at the beginning of the document. Skip links can be hidden with CSS but should appear when tabbing through pages. For example: "Skip to Search", "Skip to Navigation", or "Skip to Main Content" links. The newest version of the Common Look and Feel contains the next step beyond skip links: ARIA landmark roles and the <nav> tag of HTML5.
10. Accessible links. Make sure that text used for links is understandable when read by itself and out of context of surrounding text. Visitors must have a clear idea of where they will go if they click the link. People using screen readers sometimes check out a page by scanning the text of the links. Only use the same link text more than once if that link always goes to the same URI. Never use "click here" or "more" for link text as they don’t provide enough meaning on their own. Don’t have links open in a new browser window as this can be very confusing or not noticeable for people using screen readers. See: Links and Hypertext.
11. Identify the language of the text. This helps the computer or assistive device present information in a way that is appropriate to the language and also helps automatic translation software that translates text from one language into another. See: H58: Using language attributes to identify changes in the human language
12. Non-HTML Content (PDF, Flash). Ensure accessibility of non-HTML content, including Flash and PDF files. Techniques are referenced below to give structure and ensure proper reading order to Flash, PDF, Word, and PowerPoint files. See: Adobe Flash accessibility design guidelines, and Creating Accessible Flash Content, PDF Accessibility, Microsoft Word, and PowerPoint Accessibility.
13. Never use frames. Inline frames are better but still problematic.
14. TEST your pages during and after development.
    • Check X/HTML code validity using the W3C validator
    • For a very rough and incomplete accessibility indicator check with:
      • the WAVE tool or the WAVE toolbar
      • Juicy Studio Accessibility toolbar (including colour contrast)
      • screen readers
    • Make sure all important features/services/information are available with the following disabled: JavaScript, CSS, Flash, images, pointing devices like mice, trackballs, and trackpads.
    • Check usability of sites with various browsers. For desktop browsers check with
      • Internet Explorer 7+
      • Firefox 3.5+ or 8+
      • Safari 4+
      • Google Chrome
      • Opera
    • For mobile browsers check usability with the W3C's Web on the Move. Another checker that can also provide simulations of what your site will look like is mobiReady.
      • BlackBerry devices (OS 4.2+)
      • iPhone
      • Android
      • Opera Mini devices
      • Nokia devices
15. Learn about and use ARIA. ARIA is a series of techniques designed to increase the semantics of web content, especially dynamic content, thereby passing along dynamic content existence and chages to users of Accessible Technology (such as screen readers). An excellent resource is the Mozilla Developer Network ARIA documents. ARIA roles are part of the latest Common Look and Feel.

To reiterate, following these steps does not guarantee that the information will be accessible, however, it will greatly help. In addition to improving the accessibility of your information and services, following these steps will improve the findability, search engine ranking, and usability of your sites for all users.