Guest Post: Common Accessibility Fails

Author: 
Gaelian - Accessibility & Style
Category: 

The Department of Finance Archive

The content on this page and other Finance archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.

 

This post from Kim Chatterjee is the first in a series of Invited Guest Posts from our CoE members. We encourage everyone to get involved in the Community, so if you want to participate by writing a Guest Post and sharing your advice or views on accessibility, please let us know.

Accessibility in the online space is not just about whether a blind user with a screen reader can understand your website. It is about providing universal access and an effective user experience. This caters for the needs of people with hearing impairments, cognitive and motor impairments, but also caters for a much broader audience. It includes the guy who forgot to pack the mouse in his laptop bag and is keyboard-dependent, the lady who broke her glasses and squints an inch from the screen, the tourist who checks his online booking on his mobile, the potential international student trying to understand your instructions, and the kid who lives in rural Australia still waiting for your page to finish loading. Good accessibility = good usability.

When it comes to designing online content, the Web Content Accessibility Guidelines 2 (WCAG 2) are the standards to follow. Version 2 emerged in 2008, and today we’re relieved to see a lot more acceptance (and recognition) on people’s faces when we mention accessibility. However we’re still seeing a lot of the same issues, so we’ve compiled five of our top issues that we constantly encounter when we run an accessibility check across a site or piece of software. We want to show you WHY it’s important to fix.

1 The mystery “edit” box

Screen with unlabeled forms.  Computer says: this is a textbox. That's all I'm telling you.  Frustrated user says: Oh joy. So now if I switch to reading mode then remember where I am, and manually force the screen reader to find what... Oh never mind. I'm leaving.

When designing forms, it is important to add the necessary code to connect the label to its field -  – not just position the label next to it. “Edit” is all a screen reader might announce if you haven’t correctly assigned a label to a field even if the text is right there for all the sighted world to see.

 

2 Unsupported formats

Screen with a 'no access' sign. Computer says: There's a lot of content here but you don't have the right set up, sorry. Frustrated user says: Now what do I do?

Ever tried typing an email in English on a European keyboard? It’s not easy. Yet we see a lot of designs that assume that people all have the same computer setup that you do. It’s important to know who your audience is, and design for the most general access. Keep track of browser usage and trends but understand that your reader might not have Microsoft Word installed, or might have Javascript blocked. They might have their own style sheet because they need a particular display, or are using their gran’s computer for the day which is running an operating system that is still several versions behind. We’re not saying to design for the past, but make sure that your users can still get their job done. If a specific format is necessary, help the user to find where they can get the required bits.

 

3 Can’t get to it...

Screen with unreachable content  Computer says: Using only your mouse, hover over and click this thingo as the only way to get to really important information Frustrated user says: I'm trying!!! while hitting tab on keyboard

If you can click it, you should also be able to get to it by only using the keyboard. This is an area where visual design can sometime fail. All your navigation elements, your clickable images, your embedded widget controls, and importantly, the stop button on that annoying video that keeps automatically playing – should be controllable by using the keyboard on its own. Note that different browsers use different keyboard commands. Not all web elements are equal, and some cannot (and were never meant to) capture keyboard focus – such as text or images. If you’re making an element selectable, use the correct element.

 

4 Poorly designed PDFs

Screen: zigzag arrows showing a confusing reading order Computer says: After 'A', you should read 'B' and 'C', but we're sending you to 'R' then 'A' then 'U' and you don't need to know about this picture anyway... Frustrated user says: my brain hurts.

As painful as this sounds, yes, your PDF documents should be checked to see if they hold the correct reading order and are tagged properly. Read about how screen reader users read PDF documents (PDF, 367KB). Is the PDF the only source of information? Not good. Do they contain complex graphics that are essential to the message? Better tag these. Are they interactive? Check that they are keyboard friendly and follow a logical order. A lot of applications now have embedded features of saving a file as PDF, but this isn’t enough. The Adobe Acrobat site holds some tips on how to make various documents accessible.

 

5 Keep the language simple

Keep it simple; get to the point. Know your audience, and write for the web. Users are short on patience, but they can also have actual trouble processing the language. English as a second language, dyslexia, Attention Deficit Disorder, and other learning and cognitive disabilities should not be ignored when you are writing for your audience. Tackling these issues can be simple if considered early in the design and development process. The list does go on, but it comes to this: if you keep the user’s experience in mind and reflect this care in your design, then following the WCAG guidelines checklist will come naturally, and your users will love you forever.

Kim Chatterjee works for Stamford Interactive. The views expressed in this post are not necessarily those of the Australian Government.

Comments (17)

Not to cut Kim off, but I would encourage everyone to try to make everything more accessible, regardless of its alternative formats.

When we think about PDF, we should remember it wont always be used online next to its HTML equivalent. It will be downloaded and emailed around. Users who come across the PDF may never know there was a HTML version. In these cases especially, by tagging the file, we make it more useful and accessible to any that come across it.

Kim, more to add? Or others, how do you feel about tagging PDFs?

Thanks Kim. I wonder if it's necessary to have fully accessible PDFs if the information is presented in an alternative accessible format such as HTML?

Hi Robyn, thanks for the interest! Raven's right - the PDF will have a life of its own. The user might actually encounter it first, and later (or never) access the site, in reverse to what the designers might expect. Fully agree that everything should be made as accessible as possible.

Practically speaking, the real danger is where the PDF is the only format available. Just like any format, PDFs can be designed for various purposes and specific audiences, so can be quite targeted forms of media (sorry, it's the classic 'it depends' answer that has everyone's eyes rolling). Not all formats have a one-solution-fits-all purpose, so we encourage everyone to think about the user experience from multiple angles, and what their different starting and ending points might be.

If a particular document/format is highly specialised and clearly NOT the ideal accessible experience (e.g. with highly complex graphical or interactive content), then we'd emphasise that the users need to be clearly shown where they can go for the other experience that IS designed for them.

This might make some people breathe a sigh of relief that they don't have to worry about the PDF - until they realise they have to build and maintain the other interface. We certainly hope it's not so arduous in your case, as it sounds like you've already catered for it.

Some interesting points there!

A well designed and created PDF file can meet AA or greater compliance - even SmartForms and the like. Certainly anything you could do with a web page (short of timed media events) that meets WCAG can be done accesibly with a PDF file if the more recent (as opposed to early generation) authoring tools are used.

Which begs the point - if one can understand that PDF and X/HTML can be delivered at the same level of AA or greater compliance, would it not be safe to assume that it is not only a better practice, but also in the users best interest if both formats are written with both the online delivery and offline delivery in mind.

WCAG tells us that you shoud alt tag and otherwise describe a visual element on a web page. It also tells us that you should do it for a PDF. But the converse (which is not addressed by WCAG) holds true. How many of us print web pages off. Probably as many as print or circulate PDF files. For instance - where you would provide a written out link in a PDF (e.g. for more information visit the AGIMO website [http://www.agimo.gov.au] because you assume it will be printed, why not do the same in a .gov.au webpage - it's not only adding an extra level of accessibility to the online page (particularily in terms of trust and provenence, which is often an issue with older or non-Internet savvy users for instance), but the page itself makes sense when printed.

Just some thoughts :)

Unfortunately, this is a common misconception.

Well designed and tagged PDFs are more accessible to people, but the technology is not considered “Accessibility Supported” by the Australian Government, as there are no current Sufficient Techniques to support a claim for WCAG 2.0 conformance.

For example, one Sufficient Technique for Success Criteria 1.3.1 (Info and Relationships) is the use of proper structural mark-up in HTML. Through implementation of Sufficient Techniques, the Australian Government feels satisfied that users will be able to access content in an accessible consistent manner. Of course, agencies will need to use “Accessibility Supported” technologies in ways that are supported, or not rely on them. It would be entirely inappropriate to assume just because a website is built in HTML it is automatically accessible. Accessibility requires effort and application of approved standards.

PDF doesn’t yet have those approved Sufficient Techniques, so agencies must not rely upon them, hence the required alternative format as Kerry outlines with the AHRC notes. Similarly, RTF, DOC, XLS... etc, all require another format. We’ll look at this issue again when Sufficient Techniques become available for PDF (as well as other formats), and there are a few of them in draft now.

We have recently completed a study of the accessiblity of PDF files specifically for people with a disability and hope to release that report soon (in the next few weeks post accessible design). Once released we will commence publishing some specific guidance and resources on PDF files.

I don't understand why some sufficient techniques are marked as (HTML) when they also apply to other formats.

A basic tenet of WCAG 2.0 is that it is technology neutral. Non-W3C formats are allowed provided they conform to all of the success criteria.

Sufficient techniques such as the use of structural mark-up, headings, table headers and what have you apply to PDF and, with the exception of table headers, MS Word and RTF. And yet the sufficient techniques are marked as (HTML) which suggests that they relate only to that format.

I am surprised to hear that there are sufficient techniques in draft that relate to only one format.

Excellent points Lamont.

I think Glen's points are valid too - there are some Sufficient Techniques which (in my opinion) promote the intent of accessibility, and the relevant Success Criteria, which seem relevant to other technologies (not just HTML). What we need to be careful of however, is assuming that applying that intent will make the new technology necessarily accessible.

For instance, it appears from limited testing that marking up a MS Word document with stylised headings (like h1-h6 in HTML) would make the document more accessible through potentially programmatically determinable headings; but we don’t have supported evidence of accessibility for Word (no current Sufficient Techniques), so we cannot rely upon this technology.

It is up to vendors, accessibility interested people, trusted experts, and the W3C Working Group to submit and validate Sufficient Techniques to meet Success Criteria across different technologies, then WCAG can be applied in a more technologically-neutral manner.

And while Lamont correctly states: “It should be noted they are informative, and not normative...”, it should also be noted that for Australian Government websites, there is no other accepted means of assuring WCAG 2.0 conformance: you must use Sufficient Techniques to claim conformance, or not rely upon the technology. That doesn’t mean you need to use HTML, it means only means you cannot rely on technologies for which no Sufficient Techniques exist.

Find out more about submitting a Sufficient Technique from the W3C website: http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/

If you must use sufficient techniques to claim conformance I can't see any alternative for publications but to mark them up as HTML

I checked out the submission form and the formats that do not currently have sufficient techniques such as PDF and Word are not accessible from the drop-down menu of formats. They would need to go under general techniques.

That would explain why Adobe and Microsoft are not busily publishing techniques, and suggests that it may be some time before we see sufficient techniques for those formats.

Given that neither PDF or Word can be considered accessibility supported, what choice do we have but HTML?

That's great news Andrew. I look forward to checking out the resources you have provided.

And thank you Raven. Your clarification makes a lot of sense.

Raven, all this chat about accessibility in PDF and other formats still leaves Federal Agencies in a quandary about what to do, while we await further guidelines from AGIMO. We still produce masses of material required to be placed online much of which is only available to the various web teams, in PDF as no original word document has been maintained and the final editorial has been done directly with the designers.

The new FOI measures require agencies to publish material, possibly in large quantities, most of which will not be layout in HTML due to resource and time limitations. It is also Annual Report time with the expectation of these large documents being available for download and reading online (yes it will be in PDF and html).

Conmpanies like the Adobe Authorised Trainers, Alpha Computer Consultants, run a course on 'Creating Accessible PDF's'. So I gather the intent here is not that PDF's are non-accessible it is just that we can't validate the accessibility against WCAG 2.0 is that correct?

Thanks Kerry. I think nowadays if one publishes in one format you are inviting trouble as our 'clients' are more aware of their rights and our responsibilities.

Hi Accessibility colleagues;

Many of you are aware that we have been busy with a PDF accessibility study. Our study deals with the accessibility of the Portable Document Format when used with assistive technologies; that is by people with a disability.

It is well known that the issues with PDF are contentious for both web and business managers and so our report presents findings and provides recommendations that will be followed up by guidance.

We are not yet ready to release that report, it is currently out with the design company. However, our commitment is to release it in the next few weeks. Until then it is premature for me to commence a discussion about it (until you get the opportunity to review it too).

To foster a better understanding of the issues, when we release the report we will commence a discussion about it on the blog. As both Adobe and Vision Australia conducted the testing that supports this study we have invited them to participate in the discussion.

So stay tuned. If you have not already subscribed to the RSS feeds, then please do so that you get early access to the experts that will help us, as a government, do better with the publication of PDF files.

Chris, a quick and dirty way of creating an alternative when all you have is a PDF is to save the PDF as RTF.

It ony works with tagged PDF, so if they send you untagged PDF, open the file in Acrobat and, from the accessibility menu, choose Ädd tags to document". Then go to the file menu and choose "Save as". From the drop down choose RTF.

The formatting can sometimes get a bït screwed up, but you can clean it up in Word.

The resulting RTF will be no more accessible than the PDF from which it was created, but at least you have an alternative format.

Glen thank you. I remind everyone that there is a wealth of knowledge and experience across the APS in regard to accessibility and useability which should constantly be tapped.

Hi

I'd just like to make the comment that while accessibility in govt website is using required by policies or procedures, in the commercial world, implementing accessibility into a website is only done if real benefits will be realised.

Or am I over analysising it. Is accessibility and usability just good web design that doesn't need to cost more to implement?

A quick note on the use of language - 'Fail' is a verb. 'Failure' is the noun that should have been used in the title of this post.

Comments on this post are now closed. Please let us know if you would like to discuss this post.

Last updated: 28 July 2016