ICAWEB402A

1. The following presentation outlines issues to be taken into consideration when designing websites in order to meet and confirm accessibility for various groups of users with specific needs. ICAWEB402A

2. Website Accessibility – what does this mean? • Web accessibility refers to the philosophy and practice of making website pages so they can be navigated and read by people of all abilities and disabilities regardless of location, experience or the type of computer technology used. • When sites are correctly designed, developed and edited, all users can have equal access to information and functionality.

3. Just to be clear • Accessibility does not require that all pages be limited to plain text. More sophisticated and innovative pages can and should also be made accessible. In general, this involves provision of alternatives to an otherwise inaccessible feature, rather than any requirement to avoid innovative design. • There are four principles that provide the foundation of web accessibility; 1. Perceivable, 2. Operable, 3. Understandable and 4. Robust.

4. Legislative and Industry Standards There are several Australian Legislative acts that directly influence accessibility in a web context. • The Australian Disability Discrimination Act of 1992 (which is administered by the Human Rights & Equal Opportunity Commission) • The Australian Human Rights Commission Act of 1986 • Racial Discrimination Act 1975

5. Legislative and Industry Standards Australia is also signatory to a number of international human rights agreements the most important of which are: • ICCPR - International Covenant on Civil & Political Rights • ICESCR - International Covenant on Economic, Social & Cultural Rights • CDREO - ILO Convention Concerning Discrimination in Respect of Employment & Occupation • DRDP - Declaration on the Rights of Disabled Persons • CRPD - Convention on the Rights of Persons with Disabilities • The W3C developed and maintains a Web Accessibility Initiative(WAI), guidelines produced by WAI are regarded as the international standard. It also provides support material and resources.

6. What must we consider as designers to address accessibility? • Vision impaired users can be assisted with text-to-speech software and/or text-to-Braille hardware to understand pages but your pages must be designed to support these technologies. • Those with poor sight need to be able to read and understand the content. • Colour blind users need to be able to differentiate areas of the pages easily. • There are users who cannot control a mouse with precision. • There are users who cannot use a mouse or even a standard keyboard. • Deaf and hard-of-hearing users obviously can not hear audio content. • Some users are prone to seizures. • Some users have dyslexia and learning difficulties which make it hard to understand the content. • Non English speaking users need access too. • People with disabilities are, on average, on lower incomes and can not afford the state of the art equipment designed to help them. • It is technically possible in the modern world to remove most barriers to equal access. When sites are correctly built and maintained, all of these users can be accommodated without decreasing the usability of the site for non-disabled users.

7. How do we address these issues with design? • A site needs to be coded with semantically meaningful HTML. • Provide textual equivalents for all images and with links named meaningfully. • Use text and images that are large and/or enlargeable. • Ensure links are underlined (or otherwise differentiated) as well as coloured. Avoid low contrasting colours in layout. • Make clickable links and areas that are large enough to avoid precision use of a mouse. • Code pages so that users can navigate by means of the keyboard or a single switch access device. • Insert closed caption on videos or make a sign language version available. • Provide translations for key languages. • Avoid flashing effects or make them optional • Ensure content that is written in plain language and illustrated with instructional diagrams and animations. • Validate accessibility.

8. WAI Priority one checklist • provide a text equivalent for every non-text element (e.g. via 'alt', 'longdesc', or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g. animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. • ensure that all information conveyed with colour is also available without colour, for example from context or markup. • clearly identify changes in the natural language of a document's text and any text equivalents (e.g. captions). • organise documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. • ensure that equivalents for dynamic content are updated when the dynamic content changes. • until internet products allow users to control flickering, avoid causing the screen to flicker. • use the clearest and simplest language appropriate for a site's content.

9. Example Checklists • Images and animations. Use the alt attribute to describe the function of each visual. • Image maps. Use client-side MAP and text for hotspots. • Multimedia. Provide captioning and transcripts of audio, and descriptions of video. • Hypertext links. Use text that makes sense when read out of context. For example, avoid 'click here' and provide more information. • Page organisation. Use headings, lists, and consistent structure. Use a cascading style sheet for layout and style where possible. • Graphs and charts. Summarise or use the “longdesc” attribute. • Scripts, applets, and plug-ins. Provide alternative content in case active features are inaccessible or unsupported. • Frames. Use NOFRAMES and meaningful titles. • Tables. Make line by line reading sensible. Summarise. • Check your work. Validate. Use tools, checklist, and guidelines at www.w3.org/TR/WAI-WEBCONTENT

10. Examples of compliancy • the Australian Taxation Office at www.ato.gov.au; • the Federal Court of Australia at www.fedcourt.gov.au; • the Office of Disability within the Department of Family and Community Services at www.facs.gov.au

11. Operable user interface and navigation • Many people do not use the mouse and rely on the keyboard to interact with web pages. • Keyboard functionality also ensures access for people using alternatives such as keyboards with ergonomic layouts, on-screen keyboards, or switch devices. It also helps people using voice recognition (speech input) to operate websites and to dictate text through the keyboard interface. • Main navigation needs to be visible to assistive technology and operable using a keyboard only, you must ensure functionality of your pages from a keyboard extends to form controls, input, and all other user interface components.

12. In designing a page to meet international standards we can assess use of the following while organising our pages; • Skip navigation link – allowing the keyboard user to skip navigation links in order to reach page content faster. All keyboard users are otherwise forced to tab through all top links and side links in order to reach the main content. • Accessible menus Complex drop-down or flyout menus, e.g., with multiple columns, not only have unfortunate implications for assistive technology users, they also have a negative effect on those with cognitive impairments, low vision, or motor impairments. Navigation menus based on DHTML or Flash are rarely accessible. • Proper headings A primary navigational aid on a web page for a screen reader is the <h1> header, Screen readers can produce a list of headings on a page, from which the user can select and jump to that location on the page. So, a correctly positioned <h1> tag allows an assistive technology user to get right to the business end of the page. It is also important to make sure that your headings are properly nested, i.e. h2 follows h1, h3 follows h2 etc.

13. Meaningful link text If a page is littered with “click here” and “more” links, the screen reader user will have no clue what these links mean when they are presented in a list of links or when the user tabs through site from link to link. Likewise, using a URL as a link description can baffle a screen reader user because the screen reader will attempt to pronounce the URL as if it were a word and the description will sound like gibberish. • Document Landmark roles Document landmark roles are a specification that alert a screen reader user to the overall geographic regions on a web page; Banner, Navigation, Search, Main content, Auxiliary content, Posted content, Footer information. Landmark roles are of great benefit to screen reader users.

14. The End For further information and resources go to the W3C site.