A key issue facing organisations, government departments and businesses is how to ensure their websites are accessible. As a higher education institution, it is important for Deakin to ensure that our student’s get the best possible learning experience and those with disabilities are not disadvantaged. Access to digital material should be available to everyone.

Recently, I went along to a Web Accessibility Workshop, run by Media Access Australia. It was a two-day crash course designed to first raise awareness about websites that aren’t disability compliant. We were given a history of web accessibility guidelines, an understanding of why websites need to be accessible from a legal perspective, design, business, education and finally an ethical perspective. We also learnt about the types of disabilities that people have and the assistive technology options available to them, such as Jaws and NVDA screen reader.

After learning about WCAG (Web Content Accessibility Guidelines) 2.0 accessibility guidelines, which defines how to make web content more accessible to people with disabilities, we learnt that there were four key areas that need to be thought about when designing a website.

• A site needs to be perceivable – so captions need to be available if there are videos on the site.
• The site needs to be operable e.g if there is a carousel on the site, there should be a pause button or the ability to switch between slides.
• The site should be easily understood. There should be a language tag in the HTML, content needs to be predictable, and where there are forms to fill out, they need to be clearly labelled. When they’re not filled out correctly, an example should be given so that people can understand what the form is asking for.
• websites need to be robust Don’t make a website only compliant with a specific browser, application or screen reader. Have somebody test your website, and use a screen reader to make sure that all text on the site is able to be read out

To test a website, the evaluation scope has to be determined first. Once this is done, you can figure out what you want to test. Is it a website or an app? You then need to work out what level of accessibility the website you’re testing needs to meet. Does it meet A, AA or AAA from the WCAG 2.0 standards? A is the simplest, whilst AAA is purely for people with disabilities only. It’s not recommended that AAA is needed in most cases. What devices are you testing on, and what browser? Mac OS-X or even a mobile device?

You then need to explore the target website, and use analytics if possible to look at the most popular pages, and search for those pages which may have some unique content. Are there PDF files attached? If so, are they accessible? Do they have proper naming conventions, and can they be read by a screen reader? What are the common tasks a user will perform on this website? Is the website old or new? How complex is it, and is it a large website?

Perform some visual checks, and see how the website responds to assistive technology, such as Jaws or NVDA screen reader, and check out the colour testing. Once this is done, it’s time to report on the findings against each applicable criterion. Does the criterion pass or fail? If it fails, describe the potential issue that is occurring and prescribe options for fixing it in the audit report.

By attending this training session over the course of two days, our aim is to have our BCEL Learning Innovations Blog and CloudDeakin sites more accessible to all who use them, through improved navigation, video captions where possible, alternate text, and colour styles.