Digital

Checking for build quality

build quality check

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: digitalandcreative@uwa.edu.au

 

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

It is interesting to note that WCAG 2.0 doesn't require headings where other suitable arrangements have been made. However, a screen reader user, on arriving at an unfamiliar page, will most likely try to navigate by headings.

Screen reader users unfamiliar with pages may, after learning a page name, get the most benefit from page headings. It is the 'go-to' feature for blind and very low vision users.

Embed links

Hyperlinks on web pages may be presented either long-form (ie spelled out) or embedded under descriptive text. Best practice at UWA is to embed them – embedding a link keeps the address itself unseen and yet allows the link text to explain the destination with the added benefit of surrounding context. This is the most aesthetically attractive and least confusing option for content readers. Further, while long webpaths may allude to the content within, this asks for assumptions that are unlikely to be always or entirely correct. The breadth of modern web publishing also provides for very-long webpaths and many users may want to use ultimate destinations represented by long, unattractive, parameter formed paths.

Good example, this link will take you to the homepage for this site:

Descriptive link text

When using text to describe the destination of a link, be consistent. For example, if two or more links direct you to the same destination, be sure to use the same text term to describe them. In the same way, if links direct to different destinations, use different words to describe them. Using the same words again and again – or, worse, non-descriptive ones – will adversely affect any user.

Very common mistakes in this realm include:

  • "Click here for more", whether used once or often, and without regard to the destination.
  • "More information"
  • "Contact us" should not be used with an embedded mail address on the same site as using "Contact us" to link to a web form or information page.

For an example of how to use descriptive link, see the embed links example above.

Be explicit in the link destination text you are offering, your audience will thank you for it.

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: digitalandcreative@uwa.edu.au”. 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 format@uwa.edu.au.

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:

Abbreviations and contractions

The University offers advice on the written style of abbreviations and contractions, and has specific advice on how acronyms and abbreviations should be written in web content.

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:

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

Tables

The once frequently seen layout tables for HTML design and layout is a deprecated method unless tabular data is being displayed.

Before commencing work creating tables, consider using semantic heading styles or definition lists instead.

Specific HTML mark-up is required to ensure that tables are accessible to screen-reader users. Without this, users are unable to understand the relationships between table headers and the cells within their scope. Be sure to summarise the table, label columns and rows and avoid merging cells.

Simple Table

A simple table has a single header at the top of each column, and optionally a single header in the first column of each row. It has no nested columns or rows. To make a simple table accessible, apply the following mark-up:

  • Markup all column headers or row headers as table headers using the <th> element
  • Define the scope of each <th> using the scope attribute, the value of scope can be either “col” or “row”

Complex Table

A complex table may include nested rows or columns, and headers may be located in places other than the first row or column. These tables can be very challenging for screen-reader users to understand, so to ensure their accessibility apply the following techniques:

  • Markup all column headers or row headers as table headers using the <th> element
  • Add a unique id attribute to each <th> element
  • For every table data cell <td>, add a headers attribute that lists the id’s of all headers that apply to that particular cell
  • If more than one header applies to a cell, separate id’s with a space.

You can find an excellent accessibility tagging tool for tables at Accessify.

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> 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.

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?

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.

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:

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:

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.

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.

Mobile phone and tablet support

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

Desktop support

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.

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:

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:

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:

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:

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.

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:

Reliable resources

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

Automated testing

Paraphrased from one testing tool help page – automated tools "cannot tell you if your web content is accessible. Only a human can determine true accessibility. But, {they} can help you evaluate the accessibility of your web content."

The below tools and lists of resources have been selected, and most likely developed, as each one offers a particular feature or groups of features not found elsewhere.

Check your browsers for plug-ins and web developer tools. Some examples include:

Associated resources

Back to top