Guest Post: Common Accessibility Fails
- 15
- Sep
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
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
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…
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
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.
loading...
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?
loading...
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?
loading...
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.
loading...
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
loading...
Please forgive my ignorance here but in the context of this discussion around the accessibility of PDFs, Lamont has indicated that it is possible to create a Level AA compliant PDF. On the other blog discussion there has been a fair amount of comment about PDFs and alternate formats more broadly. In particular I am interested by the comment below:
“Gaelian – Accessibility & Style says:
September 17, 2010 at 2:32 pm
…PDF, RTF, DOC, XLS, CSV etc. etc. are not unambiguously proven to be Accessibility Supported as far as the Australian Government is concerned…”
If the Australian Government’s position on these alternate formats is that they are not unambiguously accessibility supported, an Lamont has indicated that a Level AA PDF can be created – my question is; will Level AA PDFs be considered compliant even though there is a percieved ambiguity of their being accessibility supported?
loading...
I should also add here that I am excited by the ability to create well designed, Level AA accessible PDFs…
loading...
They will not be considered compliant, according to the AHRC. Look under 2.3 at http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html
I believe their latest advice will be similar.
loading...
Thanks Kerry – that helps enormously.
loading...
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.
loading...
Thank you for that clarification Jacqui – that’s the first time (and no doubt for others) I’ve ever seen that advice – certainly the NTS makes no mention of it at all. And it does make sense.
Will AGIMO/the Australian Government be publishing a list of “Accessibility Supported technologies” which will allow for authoring without an alternate format to be supplied if the primary document is compliant?
And will the creation and existence of Sufficient Techniques as they are published be enough to place a technology on the list automatically? Or will there be a regular review period by the Government to place technologies on the list over time?
loading...
Hi Lamont
We talk about alternative formats on the Accessibility page of the Web Publishing Guide. This is the authorative source of policy advice for all FMA Act agencies.
See: http://webpublishing.agimo.gov.au/Accessibility.html
“Alternative Formats
Until otherwise stated, agencies must not rely upon any web technology that cannot claim WCAG 2.0 conformance. That is, any technology may be used, but where it cannot prove its accessibility support, agencies must provide an additional alternative format. Web technologies that claim accessibility support must prove WCAG 2.0 conformance through the use of WCAG 2.0 Sufficient Techniques.
Agencies are reminded that it is still a requirement to publish an alternative to all PDF documents (preferably in HTML). Advice on the accessibility support of PDF documents will be made available at the conclusion of the PDF Accessibility Review Project, due mid-2010. In the meantime, agencies must abide by the Australian Human Rights Commission’s Disability Discrimination Act Advisory Notes in ...
... order to mitigate risk of disability discrimination complaint.
Agencies must provide other alternative formats upon request, but should not rely on this defence, nor consider it an appropriate long-term solution to providing accessible versions. Alternative formats should always be published at the same time.” <END QUOTE>
Regarding a list of “Accessibility Supported Technologies”, it is unlikely we will create such a list, but rather will point to the W3C and promote the use of Technologies for which there exist Sufficient Techniques.
loading...
Thanks Raven – must admit I hadn’t realised the Web Publishing Guide had been updated to reflect the NTS – should of looked there first!
loading...
Not a problem – it’s always good to have opportunity to remind people of our primary channel for web policy advice! *smile*
loading...
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.
loading...
Hi Glen
There are sufficient techniques that are published and finalised which relate to only one format as well – the ones for Flash for instance.
Yes – WCAG 2.0 is technology neutral. The Sufficient Techniques exist only to show how to meet any specific WCAG guideline in general using any technologies or languages (General ST’s), a specific language (e.g. HTML) or a specific technology (e.g. Flash). It should be noted they are informative, and not normative (i.e. they assist in understanding but set no requirements themselves in meeting WCAG)
So yes, the General Sufficient Techniques you point out can be used for PDF and other formats, and are meant to be. However any Technique marked specifically to a language or technology is likely to be written so that it only applies to the language or technology in question.
For instance: take an X/HTML technique such as H42: Using h1-h6 to identify headings. ...
... You’ll note that this is a language specific technique which expands on G141: Organizing a page using headings.
However H42 could not actually be used for a PDF, MS Word or RTF document, as it involves formatting markup using X/HTML code in a certain way, and one really would not actually normally edit the code of a PDF, Word or RTF file directly. Hence why a corresponding PDF Technique (which may still be called “Using h1-h6 to identify headings”) would be written explaining how to accomplish the same thing using PDF authoring software.
loading...
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/
loading...
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?
loading...
Agencies may elect to publish web content in any format it feels is appropriate. Where agencies cannot prove conformance to WCAG 2.0 through the application of Sufficient Techniques, they can still publish in that format, but cannot rely on the technology, and so must provide two formats.
Doing so will be considered consistent with the National Transition Strategy and Accessibility mandate (provided on the Web Publishing Guide – see quoted section from my comment on 28 September).
This moves us into a position of potential non-conformance with WCAG 2.0 specifically, but promotes non-discrimination. If we simply allowed agencies to publish in only one format which didn’t have Sufficient Techniques, and imposed no other qualification for accessibility conformance, we would be both non-compliant and very potentially discriminatory.
Understandably, it is not a perfect system, but it is a system we have had in place for a number of years.
So how will agencies ...
... manage this?
Common choices to non-HTML for publications include PDF, RTF, MS Word, Open Office, plain text, and in some cased MS Excel or CSV. Agencies need to elect two formats, but it doesn’t always need to be the same two. They should consider the needs of their audience and intent of the document and plan accordingly.
Many agencies may choose to publish in HTML, but this has its limitations too in being available offline and easy to download (for less computer-literate users). People expect to be able to download government publications, so agencies would be well placed in providing content in this way.
The application of this allowance, while not specifically stated, is intended for primarily government publications, and not entire websites, and is driven to a degree to the typical publishing processes of this kind of content.
loading...
Glen (and others),
It is correct to say that there are no finalized techniques for PDF accessibility that exist on the W3C site, but it is not correct to say that Adobe is not busily publishing techniques as in fact, we are.
Last week, for example, the WCAG working group accepted 3 new techniques for PDF in order to comply with WCAG 2.0, and there were techniques in preceding weeks. We have just gotten started getting techniques accepted, but have many more in draft form that will be evaluated (and I am hopeful, accepted) by the working group and included in the next update of the WCAG documents (~6 months).
The next update of the WCAG documents, which I expect in a very short amount of time, will include techniques for Flash accessibility, so we’ve spent time looking at those also.
If anyone is interested in looking at the PDF techniques in draft ...
... and making comments, or contributing techniques to the effort, please do let me know. My email is akirkpat@ [the company that makes Adobe Reader].com.
Draft techniques:
http://trace.wisc.edu/wcag_wiki/index.php?title=Category:PDF_Techniques
Accepted techniques:
http://trace.wisc.edu/wcag_wiki/index.php?title=Category:PDF_Accepted
loading...
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.
loading...
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?
loading...
I think the intent is … that PDFs can be made accessible, but that many are not. The AHRC sums it up thus:
“The Portable Document Format (PDF) file system developed by Adobe has become widely used for making documents available on web pages. Despite considerable work done by Adobe, PDF remains a relatively inaccessible format to people who are blind or vision-impaired. Software exists to provide some access to the text of some PDF documents, but for a PDF document to be accessible to this software, it must be prepared in accordance with the guidelines that Adobe have developed. Even when these guidelines are followed, the resulting document will only be accessible to those people who have the required software and the skills to use it. The Commission’s view is that organisations who distribute content only in PDF format, and who do not also make this content available in ...
... another format such as RTF, HTML, or plain text, are liable for complaints under the DDA.”
(http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html)
loading...
Interestingly, those same words apply equally to HTML or any other format.
“HTML/Word/RTF/anything written on a screen remains a relatively inaccessible format to people who are blind or vision-impaired. Software (screenreaders/AT’s) exists to provide access to the text of some HTML/Word/RTF/anything other content, but for these to be accessible to this software, it must be prepared in accordance with the guidelines that the W3C have developed, called WCAG. Even when these guidelines are followed, the resulting content will only be accessible to those people who have the required software (ie: own a screenreader and a free reader program called a browser) and the skills to use it….”
Also ironic is that, being the lead agency, the AHRC doesn’t have a page that validates only to the minimum level they themselves have mandated -the site has no alt tags, broken skip links, no form labels etc, all PDF’s have an alternative format ...
... of Word.
Rather than being an open criticism, I simply believe that no one should be exempt, and that if you are the lead agency for any area, then you should lead by example.
Thoughts?
loading...
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.
loading...
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.
loading...
Jacqui and Raven,
I’m happy to hear the PDF report will be released soon.
I look forward to seeing the final product.
Almost any technology can be either accessible or not-so-accessible, how it is implemented by authors and supported by AT is the key.
The discussion will surely be very interesting.
You have done a fantastic job with your update to your web standards in taking a reasonable and balanced approach.
I hope it takes hold across other jurisdictions.
Steve.
loading...
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.
loading...
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.
loading...
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?
loading...
Implementing accessibility in websites is, like impementing ramps in buildings, required under the Commonwealth Disability Discrimination Act 1992. This is a lesson that SOCOG learned in 2000.
Accessibility, IMO, is a basic component of good web design that does cost a little more to implement – but not as much as some people fear.
loading...
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.
loading...
Comments on this post are now closed. Please let us know if you would like to discuss this post.
loading...