Opportunities and tools for evaluating web accessibility.

Assessing web accessibility may start at the beginning of a ground-up build or it may be editing a few words in an existing, live web document. Whatever the case, there are tried, tested and recognised methods to gauge and engage with the quality of the web experience.

Digital and Creative Services at UWA will support you in this work; please let us know your intentions or needs as soon as possible because it is often more efficient to address web accessibility qualities early in conception and builds.Email: [email protected]

Text Elements

Semantic headings

Semantic headings are used to divide long documents into navigable sections. Information is grouped sensibly or logically, with smaller components arranged under headings related to them, either singly or as a group. These groups may in turn be grouped singly or with others under a more significant heading.

The most significant heading is numbered one (1), the least significant recognised heading is six (6).

When well-implemented, headings are the most easily navigable and sensible structure for information categorisation and sub-categorisation.

• <h1> - heading one, recommended to be reserved solely for a unique page name per website
• <h2> - this is heading two - for site name use, often repeated for every page in a website
• <h3> - heading three
• <h4> - heading four
• <h5> - heading five
• <h6> - heading six

Show 'mailto'

While many users of the University website may have access to personal devices on which web browsers seamlessly act with email accounts and allied applications (apps), there are likely to be many users who do not. University Library and computer laboratory users, for example, share machines where their own email accounts are not in sync with web browsers. To cater to these users and those operating multiple email accounts, we suggest exposing email addresses and not embedding them behind link text.

The format of this mailto address allows users to see the @ sign and so recognise a mail link and act accordingly. Users who have email synced to their browser will experience no ill effects from this design. Furthermore, there is an expectation that a web link will be behind embedded text. To click on it and be directed to a mailto may reasonably be seen as jarring.

A good example of how to present a mailto is “Email: [email protected]”. Notice the use of the word "Email" before the address, clearly introducing the upcoming mailto.

Underlining and underscores

Web publishing uses underlining, together with colour, colour changes and other techniques, to denote hyperlinks and to separate links from surrounding copy.

The use of underscores may therefore cause problems in expanded links (that’s to say links that are not embedded). Onscreen hyperlink underscores may disappear into underlines and be rendered unseen to users. Similarly, when an email address is printed to paper, underscores may disappear into the printed underlined address: for example, poor_email_underscore [email protected].

It is important not to use underlining as a formatting style on text, or underscores in hyperlinks. Where underscores exist alter these to hypens, <ndash> or <mdash>.

Lists

Use hypertext mark–up to create lists, numbers, tables of content or bullet points. Correct and commonly understood mark–up will be received best by accessibility users. What’s more, web readers may 'scan' pages for items of interest (more so than print-out readers). Separated lists and conveniently anchor-linked tables of content help a user quickly scan and navigate a page, and are highly recommended formatting techniques.

Markup for these will commonly be:

• ordered list — <ol> and <li>
• unordered lists — <ul> and <li>
• definition lists — <dl>, <dt> and <dd>

Where rows of hyperlinks are listed separately from sentences, UWA commonly denotes them by adding a styled bullet-point graphic before the link. Testing shows this attracts attention for the 'scanning web reader'.

Font

UWA has our own custom and mandated font, but it’s nonetheless important to remember the importance of an easily legible font. There is little quality research that defines what makes a great font for all users; some value judgements have been made, however, for providing good design, cognition, legibility and readability for most users:

• sans serif font (it's UWAs assumption that not all user screens are of leading design)
• sentence case written style
• complimentary colour contrast
• left alignment of text.

Abbreviations and contractions

The University offers advice on the written style of abbreviations and contractions.

Back to top

Language

There are two very different language concerns in web accessibility.

Reading level and cognition

Cognition is a significant consideration when considering web content and its audience-suitability. Much of the University’s content may be written for readers with significant English language sophistication, setting the bar quite high when it comes to testing the 'readability' of text. The University is also an English-language teaching institution with agreed levels of competency for student enrolment.

It is important to acknowledge, however, that in many circumstances our content must appeal to readers in early high school, readers for whom English is a second language, and people in a busy world who will appreciate easily accessible language and concepts. The standard and type of language used should match audience needs.

Be aware of the written style used and the needs of the audience. Many automated web-accessibility testing applications include algorithms to suggest the number of years of education required to read content. Microsoft Word also offers something similar within its Spelling and Grammar feature.

Advice for The University of Western Australias written style may help you.

Language tag

If your audience is composed of mainly English readers, mark–up with the lang=en tag. This enables screen-reader and browser software to correctly recognise the language intended.

Ensure that any non-English content is properly indicated with any alternative language mark-up tag. This will assist browser function and help with search engine optimisation.

Back to top

Colour

Perception

Some people won't see colours or differences between colours, so avoid using colour to communicate information unless you also provide alternatives.

For example, a web page has a white background with black text. Hyperlinks are shown as blue, unless they have been clicked already, in which case they are brown. What happens if the reader can't perceive the difference between black, brown or blue?

One solution is to ensure all links are also underlined, and that screen readers recognise and audibly announce them (or even list them all). In this way, colour-blind and unsighted people are given options to perceive the links as distinct from body text.

Avoid using colour alone to present content – 'go to the red column’ would be particularly problematic for those with red colour blindness, for instance. Where colour isn't the only method used to convey information it may be possible to use colour as a signifier, but have a good understanding of the design constraints and effective testing regimes in place when considering this.

Contrast

Sufficient colour contrast, accessible colour choices and complementary combinations are hugely important for colour-blind users and those with cognitive difficulty. Use web designs and development that allow for high-standard default colours and customisation to suit individual needs.

The concept of colour standards in web publishing includes the ideas of:

• colour sensitivity — negative reaction to high contrast; low perception of low contrast
• colour blindness

Some users will also appreciate the ability to apply their own customised style sheets (CSS) without issue. Examples of this include:

• adding a high-contrast white text on black design and omitting decorative images (perhaps for people with low vision)
• using less contrast, such as mid-blue or dark yellow text on black (for contrast-sensitive users).

CSS customisations like these can be very specialised and so are more easily built and applied by individual users. Low vision users may combine the colour changes with browser and screen magnification depending on their accessibility needs.

Testing for colour

Color Contrast Analyzer is a downloadable service that tests two colours by pixel-picking from screens or adding colour hexadecimal codes, and scores them against Web Content Accessibility Guidelines.

Online colour testing is available via:

• Webaim Contrast Checker
• Check my colours
• Contrast checker

There are a number of plugins available for web-publishing tools – look within your existing tool sets – or for more details, see this 50 minute presentation on web and colour.

While there are many technical tools for checking for image accessibility, the human check of looking at an image where its colours have been inverted is a quick and enlightening option.

Back to top

Images

In web publishing, images are powerful tools for imparting feelings and information. As such, be aware that how you publish them may either include or exclude accessibility users, based on whether they too can receive what’s being imparted by graphic designs, pictures, colours and info-graphics alone.

Information provided by images such as JPEGs, GIFs or TIFs, and by pictorial content such as graphs and maps is not accessible to people who are blind or vision-impaired and who rely on Braille or synthetic-speech to read computer screens. An alternative representation of the information, preferably as text on an HTML page, should be provided where possible.

Images may broadly by split into two groups: those that provide information and those that are purely decorative.

Images that provide data and information should include coding or a closely associated explanation that explains to accessibility users what the image offers, as well as descriptions of the image’s content and its intentions.

It is important to be specific. If an image of an aircraft has an alt description of "plane", a visitor using a screen reader may not know whether the image is of a carpenter's tool, a stretch of land, an aircraft or a two-dimensional object. A better description would be "A Qantas 737 aircraft in flight".

If images are used solely for decorative purposes, they should be added to the page using CSS, not with the HTML <img> element. If for some reason an image needs to be added using HTML, the <img> element must have an empty alt attribute <alt="">. This is a recognised technique for communicating to screen readers that the image may be ignored. The idea is that the page imparts necessary information to screen reader users while omitting additional burdens.

Mark-up language most commonly allows for:

• <alt>
• <title>
• and <caption>

for images.

Use image <alt> text to quickly describe simple images for those who cannot see them or see them clearly.

For complex images such as a chart, map or diagrams, alt text can be supplemented by:

• extended captions <caption>
• ARIA tagging, using <aria-labelledby: with the description kept in content marked with an ID tag
• HTML5 <figure> and <figcaption>
• or descriptions in closely associated text and clearly labelled files.

Long descriptions <longdesc> is not consistently supported by screen-readers or available to non screen-reader users. It was an HTML4 specification not included in HTML5.

Detailed online training on image tagging is available.

Infographics

Infographics use icons, art, text and workflow arrows to convey complex interrelated information in print and on web pages.

The same information may be delivered to accessibility users in words or by taking the effort to code the infographic sufficiently so that the relationships between data may be delivered effectively to accessibility users. One example where the effort has been taken is in this animated Staff appraisal device.

Not sure what's a decorative image and what's an informative image? Apply alt text, no harm will be done.

Back to top

Mathematic and scientific content

For STEM (Science, Technology, Engineering and Mathematics) content, follow the guidelines for creating MathML compatible equations.

There is leading work being done in this field by the people at MathJax.

Did you know that MathML is available to braille readers through assistive technologies and add–ins?

Back to top

Animations and video

Video and audio files should be audio captioned, audio described and/or transcribed for those who cannot hear the audio content.

Additionally, if your content includes an animation, make sure that it’s necessary for the content and that its flicker rate is lower than 2 Hz (Hertz) and greater than 55 Hz. Animations within these frequencies may trigger epileptic seizures.

Avoid auto–play. Moving content can be disorienting for people with cognitive disorders. These users will appreciate the ability to exercise the option to start moving content, audio, video and animations themselves, rather than having them commence unannounced.

See the advice we have for video hosting at UWA.

The good news is that accessible audio techniques received an Emmy Award in 2016. The concept is truly in focus.

Back to top

Files

Web etiquette advises that a link to a file should be pre-announced with the file type and its download size.

Showing a file’s type and size may be automated within a CMS and is best practice. Those who don't enjoy certain file types for accessibility reasons or not having compatible software will be grateful not to waste time downloading and opening an unappreciated file. Similarly those managing download speeds and capacities may also prefer the chance to open or ignore a file depending on its size.

Using file divs in Mysource Matrix automates adding file type and size as text, and adds an icon image representative of the file. File metadata is an additional option in this instance too, adding further information that’s not otherwise available without downloading or opening the file.

The accessibility of a file’s content may be looked at as a separate concept.

Alternative file types to PDF

Portable Document Format files (PDFs) can be made accessible but the process can be very complex. It is often quicker to provide content in an alternative format such as HTML, Microsoft Word or text. The alternates often provide a better web experience, begging the question, why is a PDF being added at all? See:

• 'PDF Myths page' for an expansion on PDF strengths and weaknesses
• Creating accessible P.D.F.s from InDesign

Big screen presentations – PowerPoint and Keynote

There is often a very interpersonal component to screen presentations, and accessibility users may be disadvantaged by in-person presentations without timely recourse to alternatives. For this reason, we have created support advice for accessibility and screen presentation file types, like Powerpoint and Keynote.

Are you able to provide to audience members an accessible or alternative version of a presentation? Publish it simultaneously!

Word processor files

Making content web-accessible in desktop applications and Microsoft Word follows the same principles as creating documents native to the web. The method for applying those principles may change from update to update or in different processors but the theory stays the same.

Microsoft support for accessible Word files upholds the idea of headings, alt text for images, meaningful link text and universal design. They also offer a Microsoft Word Accessible Template Sampler.

Clipboard pasting from files into web publishing brings unwanted, corrupting mark-up. If you must paste, do so into raw HTML areas.

Back to top

Menus and navigation

Good site architecture suggests that there be more than one way for a user to move between pages, so that where one method is unsuitable another type may be better.

When using drop-down and floating menus, provide a text-based navigation as well. Many users on screen readers or who have motion disorders may find floating menus problematic, drop-down menus can be problematic for some with cognitive disorders.

Use skip navigation strategies to ensure that users on a keyboard (including those on a screen reader) can skip repetitive navigation, such as navigations or menus found on similar pages in a site.

Breadcrumbs typically signify how deep into a site architecture a user has moved and what options exist to move higher into site architecture.

Web Information Architecture (IA) and User Experience (UX) sub disciplines offer much best-practice and evidence-based research into quality site menus and navigation. Leading discussions on good menu design may be read at:

• Building Accessible Menu Systems - highly recommended
• Accessible Mega Menu Test Page
• Awesome Accessible Tabpanel
• Don’t Use ARIA Menu Roles for Site Nav

Titles and headings

If a user has come to a page via low-quality links, it will assist them greatly to know straight away exactly which page they have arrived at. All HTML pages should have a unique title, often using heading 1 (one) that is readily available to accessibility technology. Often using heading 2 (two) will help to dispel any doubts or concerns.

Use headings, distinct link text and ARIA landmarks to facilitate navigation with a screen reader.

Focus

Menu-hover and rollover effects that work with a mouse should also work with keyboard focus.

Back to top

Web forms

Make sure online forms comply with accessibility standards including use of:

• quality labels for fields
• accessible error messages
• client-side form validation prior to final submission.

Spam and CAPTCHAs

Web forms, due to their high level of automation, are very efficient at electronically capturing user data. However, this automation brings a liability to attack by malicious web users, who create web 'bots' to search for and fill in web forms, often with damaging content or towards some further purpose. To combat this, tests may be used to verify human interaction – a favourite is CAPTCHA (Telling Humans and Computers Apart Automatically), released in 2003.

While very popular, however, CAPTCHA has hardly ever been accessible. (It has also been found to be fallible to advanced bots, therefore providing an unwarranted perception of security). CAPTCHAs often ask users to type in the correct letters from a grainy picture into a poorly labelled text field, or to click on six indistinct images out of ten that include a certain visual element. Clearly this is of limited or no use to the visually impaired. Alternative CAPTCHA types include requests to describe sound, but people with poor sight may also not have the best hearing.

Many web professionals have written public posts and code demonstrating how to prevent web-form and automated email spam. Consider these techniques before implementing CAPTCHAs:

• Allowing for form validation
• How to build a spam-free contact form without CAPTCHAs

Back to top

Dynamic content and interaction

If your interface includes updated information such as confirmation and error messages, ensure they are available to screen readers and are delivered in close relation to the items already onscreen and at issue. ARIA techniques are especially helpful in these cases: consider ARIA live and role:alert.

For redirects or timed actions (such as clicking ‘OK’ to remain logged in), be sure to provide adequate response time for users of screen readers and users with mobility impairments. In some cases a redirect should be replaced with a static page containing a link.

Modals and Pop-ups

Modals, pop-up windows or lightboxes need to be checked for screen-reader and keyboard accessibility. Historically these have been a frequent source of user keyboard traps.

An example of a good modal build may be seen in the Pennsylvania State University advice page.

Scripts

When using scripts to generate web content, be sure all inserted content includes appropriate accessibility features and mark-up.

Back to top

Audit and test types

It is fair to say that the most efficient method to ensure compliance with accessibility standards is to integrate their concepts into all functions in the publishing and content-production processes.

It is commonly accepted by industry leaders that no automated testing currently creates significant compliance to web standards or human needs.

Knowing all tenets and how to apply them, testing and iterating in an ongoing process may ensure the highest possible levels of web accessibility.

We advocate this Website Accessibility Conformance Evaluation Methodology.

Back to top

Mobile phone, Tablet and Desktop devices

UWA has good intelligence on how its audiences access its web information, and effort goes into ensuring that the most generous segments get the particular attention they need. For example, the detailed unit content aimed at future students is accessed most often on desktop-sized screens, whereas promotional or first-point-of-contact pages may be more frequently accessed on mobile screen sizes.

Knowing that all screen sizes are in use, we most often design, test and employ a responsive web experience by size and design for our audience.

It is important to ensure that the native and add-in accessibility features of each environment and its popular devices are able to access our content. Good practice from web design to implementation will help with this.

Advances in touch-screens and mobile devices in personal computing have added improvements for many accessibility users. In mobile phones, for instance, audible GPS-enabled map and navigation features enable unsighted pedestrians to navigate independently.

Expanded advice on mobile topics.

Mobile phone and tablet support

An in-exhaustive list of accessibility options for smart phones and tablets includes:

• Android Talkback - inbuilt
• Apple VoiceOver - inbuilt
• Windows Narrator - inbuilt
• Adobe PhoneGap - Cross platform accessible apps. creation

Desktop support

• NVDA - Windows only - free and very well featured
• JAWS - perhaps the leading screen reader.JAWS is available at UWA Reid Library Resource rooms together with Zoomtext, Dragon, Texthelp Read and Write Gold and Magnalink by arrangement. JAWS is relatively expensive to buy.
• Windows Narrator - inbuilt
• Apple VoiceOver - inbuilt
• ChromeVox - free browser extension

Back to top

CSS

Ensure that reading order is the same by disabling CSS styles. This is easily achieved in View menu-bar options on many browsers (look for No Style in Firefox). Users who have added their own CSS for accessibility reasons will benefit from receiving the page as semantically intended for original users rather than custom CSS users.

Current standards for CSS at UWA fall within the realm of CSS2 and the backwards-compatible CSS3.

• Accessible CSS – how to advice
• Online CSS validation service

Back to top

Javascript

Javascript and its associated libraries form one of the main pillars for creating web content.

Some accessibility devices do not work with javascripted features in web content. These devices essentially do not recognise javascript, or indeed actively turn if off so that other features may be enabled.

Ensuring that javascript-disabled content is accessible is a deprecated W3C standard. This was decided when the WCAG moved from 1.0 to 2.0 in 2008, due to the number of javascript-enabled accessibility devices. However, it remains a good test of semantic design to look at behaviour without javascript enabled, and to discover cases of inaccessibility. Furthermore, the testing required to prove or disprove accessibility in javascript-heavy web content is less likely to be accurate for all users.

Build and test your content to ensure that it works with javascript disabled. This may be accessed through developer toolbars available to most modern browsers.

Many of the needs that inaccessible javascript development commonly fails to meet are addressed in:

• Writing JavaScript with accessibility in mind
• JavaScript Accessibility 101

Back to top

ARIA - Accessible Rich Internet Applications

In many cases, making the most complex content and designs available to accessibility users now falls to ARIA.

When it comes to achieving accessibility compliance we suggest that all good content, mark-up and CSS decisions are applied before ARIA is considered. While offering many features to accessibility technologies, the take-up of landmarks made by ARIA is well behind that of the preceding best practices. For example, when screen reader users arrive at an unfamiliar page, they will be more likely to listen to “all headings” or “list all links” than to take up higher functioning ARIA features. This means they will be best served by the presence of well-constructed headings and meaningful links.

You will find many technical resources for ARIA in professional repositories, such as:

• First rule of ARIA use
• W.3.C. recommendation for ARIA standards
• GitHub
• MooTools
  
• Hans Hillen
• Open Ajax Alliance (OAA)
  

ARIA features will over-ride native HTML mark-up in browsers. Separate ARIA from link, button and span mark-up and avoid using menu or menuitem!

Back to top

HTML5

Mark-up in HTML5 includes a great many features that are available to the browsers of accessibility users without needing specific ARIA additions. However a good number of features are not available to all browsers yet – it is the job of the browser developers to add these improvements and perhaps to ensure assumptions on accessibility are tested as reasonable. Until the popular browsers are up-to-date in accessing HTML5 mark-up features you may want to check your intentions against this quality resource:

Current accessibility support status of HTML5 features across major browsers.

Back to top

Document type and Character set

Doctype

While once very influential in affecting browser interaction with content, adding document type to the beginning of site code is now much less important. However, because it is of little cost and it can negate the 'negative browser quirk mode', please consider the small effort of adding a reasonable mention of document type. For advice expanding on this, see:

• Accessibility and Doctype
• Recommended list of Doctype declarations

Charset or Internationalisation

Because a great deal of accessibility technology is machine-based, it is important to machines interacting with the code that they know the set of characters a site uses. Given that accessibility machines may have been manufactured for just one of the world’s many language and character sets, they may not necessarily default to or immediately recognise Australia’s most common 'utf-8' without being told to do so. Please meta tag and include the charset in your site uses.

Declaring character encodings in HTML

Back to top

Study this discipline

We haven't competed all of the free courses yet, if you complete the TT course perhaps you could let us know what you think of it? The paid University of South Australia course is excellent and recommended. It has an international intake and luminous alumni:

• Ryerson – Professional Web Accessibility Auditing Made Easy
• Ryerson - Digital Accessibility as a Business Practice
• University of South Australia – Professional Certificate in Web Accessibility
• Department of Homeland Security Trusted Tester (TT) program
• Deque University - curriculum
  

Reliable resources

You may wish to consider international commentary and resources available by leading practitioners and policy makers, like:

• World Wide Web Consortium (W.3.C.) — Accessibility Evaluation Resources (highly recommended)
• World Wide Web Consortium (W.3.C.) — Accessibility Conformance Testing (ACT) Rules Format (for self testing guides)
• Paciello Group Resources — (U.S.A. focused)
• Section 508 guidance — (U.S.A. focused)
• BBC (British Broadcasting Corporation, United Kingdom) — XHTML Integrity Standards v2.0 — (U.K. focused)
• Nielsen Norman Group - Jakob Nielsen — evaluated user experience (UX) commentary
• Centre for Accessibility - in Western Australia, new in 2018.