Good document design is the key to accessibility
- 30
- Nov
The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability
The web accessibility thread remains the most popular of our blog themes. Thanks to the work of Jacqui and Raven, it is the place to go to for relevant and reliable information on online accessibility issues in the Australian Government context. This trend continues today with this post heralding the release of the Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability.
When the Australian Government released the Website Accessibility National Transition Strategy in June 2010, it noted that “New technology has huge potential to make life better for people with disability, but we need to make sure that it is as easy to use as possible for all members of our community.” Online accessibility depends on the manner in which documents are presented and how they interact with the assistive technologies that are increasingly available.
The Portable Document Format (PDF), first created by Adobe Systems in 1993, now in its ninth version, is very widely used for online documents. While it has wide utility, its suitability for accessibility purposes has been criticised. In 2010, AGIMO, working with Vision Australia, and with the cooperation of Adobe, undertook a study of the PDF format’s accessibility capabilities. The study’s scope was focussed on the PDF format and was designed to increase understanding of its strengths and weaknesses.
The main points of the Study are:
- Poor document design makes for poor accessibility.
- Publishing tools and formats, like PDF, are improving but aren’t a substitute for good design.
- The Web Accessibility National Transition Strategy shows the way ahead for improved accessibility.
The study’s main and supplementary reports can be found on the Department of Finance and Deregulation’s website. Your comments are most welcome.
loading...
Well done team, a very well balanced report, from what I can see of the summary report.
As someone who loves the impact of rich presentation and experience, the accesibility debate has always torubled me. I often rallied against what I would call ‘reverse discrmination’ where rich online experiences were somewhat targetted as being unethical – in that they were not accessible.
My sense of social justice and the art in my heart have long battled. Hence, most of career I have explored how to create rich experiences in an accessible way. It’s not been easy and as the tools for rich experiences have matured it’s got harder to keep up.
I also felt compelled to argue against the use of accessibility as a justification for poor UX work and a downgrading of the importance of visual clues in online experiences.
The great thing about WCAG 2 is the emphasis on “alternative” versions ...
... and with the great XML (and similar) formats, we now have the ability to create different versions for all sorts of needs.We can create highly accessible versions and visually rich versions using the same content. Just as we can create versions for mobile devices, etc
The use of PDF is the most troubling area. As we all know, PDF can be accessible. The issue is that is most often not. The most pressing issue is that government sites are full of these iincorrectly produced PDFs. The social justice side of me is upset that there is a lot of important content not able to be read by a significant and important section of the Australian family.
It’s going to be a battle to sort out that mess but for all content created going forward, I believe it is the “alternative version” mantra that needs to be driven home and I think that AGIMO has a huge role to play in getting the simple message across – create what you want how you want but always provide a clearly marked accessible version that conveys exactly the same information, context, and meaning.
So, yep, well done AGIMO
loading...
Having now read the report a couple of times I see nothing new just finally an official statement which sets out the way forward and offering all APS publishers a stable and level environment. I am very please by the input of Vision Australia who are our primary advisors.
I am sure many of my peers do publish, or try to, with the various users groups in mind. Having a formal document like this enforces our stance when making demands of the product owner(s) and the requirements to supply more than one format.
Well done team!
loading...
This evaluation is very interesting. Was an evaluation performed of other formats (HTML, XPS, or others). If so, are similar reports available on these formats as well?
loading...
Thanks Lukasz, great question.
No, we haven’t conducted evaluations for other formats, and its important to note this study was for the Portable Document Format only (it doesn’t seek to compare PDF to other formats).
At this stage we are not looking to conduct similar reviews for other formats, but are taking the position that formats need to conform to WCAG 2.0 to be “relied upon” (see comment below).
loading...
Some really interesting information, thanks. I’m curious about the impact of this on authors – if authors can’t deliver information in PDF alone, are they allowed to:
1) Provide a document in HTML only?
2) Provide a document in Word only?
3) Provide a document in ODF only?
4) Provide a document in RTF only?
5) Provide a document in plain text only?
6) Provide a document in PDF and any of 1 – 5?
loading...
Hi Jennison
Our Accessibility page on the Web Publishing Guide addresses this issue:
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.
See: http://webpublishing.agimo.gov.au/Accessibility.html
Or, to your questions:
1 and 5: Yes, provided they use WCAG 2.0 to conform*
2, 3, 4: No
6. Yes
* I would caution against using plain text as a primary format in most cases due to its lack of functionality, for most government publications, plain text would not suit.
This position provides agencies the autonomy to use formats that best suit their needs.
loading...
Hi, Raven.
Thanks for the responses. A couple of follow up questions if i could:
1) So if I understand things correctly, what you are saying is that PDF/DOC/RTF/ODF are not sufficient on their own, but if you use two formats that aren’t sufficient on their own that together they can be. Is this correct?
How will authors address this in conformance claims?
2) If techniques for PDF or Word/ODF/RTF are developed for WCAG 2.0, will that
mean that authors can use these formats? I think that I heard that techniques for additional formats are being approved by the WCAG working group. Will the
publication of techniques for PDF or DOC signal to authors that these formats can be
used on their own?
loading...
Hi Jennison
Using two non-conforming technologies would still be non-conforming.
At least one format, for which Sufficient Techniques are published, must be used.
Publication of Sufficient Techniques for a technology means they can be “relied upon.” In WCAG parlance, this means they can be used if it is done in a manner that meets the applicable Success Criteria.
loading...
Great news: the Association for the Blind of WA has translated the PDF Accessibility Study into the DAISY format.
loading...
Is anyone planning (or completed) development of a utility to parse web pages for machine detectable non-compliance?
Does anyone know if such a utility already exists?
loading...
Hi Dominic
There are a couple of good automated tools out there, but WCAG 2.0 needs human testing too… we cannot rely on just a machine.
One common example of this is for SC 1.1.1, where a machine can check for the availability of alt attributes for images, but cannot check the validity or appropriate use of alternative text.
I’d be interested to hear from people about what Success Criteria can (and should) be machine tested… and recommendations for a testing methodology.
loading...
I’m just looking through the WCAG 2.0 SC to see which ones may be machine detectable, so that we can build detection into the CMS content preparation tools.
The idea is to have WCAG 2.0 assessment built into the publication workflow, automating where possible to assist the assessor.
loading...
Absolutely! In my opinion a two-pronged approach in the publishing workflow works best. That is, using tools or processes to automatically detect errors where they occur before publishing (so the web manager fixes prior to going live) and after publishing (so the web manager can address in audits or reviews*).
Teaming this with education for content authors on accessible design would take care of many accessibility issues.
* One benefit of auditing includes opportunities for web teams to assess common failures – if the site fails colour contrast a few times the web team may like to work with visual designers and communication areas to promote better contrast awareness (or update the organisation’s style guide to meet WCAG 2.0)
loading...
We’d like to share with you an error in our ways and hope that our learning can indeed help this community.
In our development and publication of the PDF and HTML versions of this study, we spent considerable time helping our designers convert the InDesign files to formats optimised for accessibility. As many designers are relatively new to accessibility design requirements (especially for PDF) we provided ours with guidance and links to Adobe educational material, to assist them with the conversion and help ensure we were producing the most accessible set of PDF documents we could.
After lots of consultation, checking, fixing, and validating, we found we still didn’t get it right. Our designers followed a logical process to create the files:
1. Assign tag elements to the style sheets.
2. Check alt tags for images in InDesign.
3. Tagged items for the reader to skip as artifacts.
4. Generate the PDF using Acrobat 9 ...
... pro, using the settings: compatible with Acrobat 6 (v1.5); optimise for web / create tagged PDF / including bookmarks and Hyperlinks.
5. Open the PDF in Acrobat and rotated landscape pages.
6. Selected the ‘Order’ panel from the ‘View/Navigation’ menu to check the text flow and amended as needed.
7. Selected all pages in the document then right clicked to select ‘Page Properties’ and checked ‘Use Document Structure’.
8. Selected ‘Properties’ from the ‘File’ menu and edited the properties and language of the PDF.
9. We then ran the full accessibility report using acrobat (with no errors).
10. Selected ‘Read Out Loud’ and listened to a few select pages.
11. Saved and closed the file.
They also used Adobe resources: http://tv.adobe.com/watch/accessibility-adobe/preparing-indesign-files-for-accessibility/ and assumed that with no errors given from the Acrobat Accessibility Checker’ it should have generated an accessible PDF.
WRONG!
Post delivery of the PDF files to us we spent some time checking accessibility for ourselves and asked Vision Australia to do a rudimentary check of the accessibility. Together we came up with a number of errors with missing tags, unordered lists and numerous issues with table structures (which wasn’t surprising with that many tables). Our designer commenced work on remediating all these issues and provided a second, third and fourth set of ‘accessible PDFs’.
After much discussion and checking we accepted what we believed to be the most accessible files we could develop and published them with a HTML version on finance.gov.au.
… more to come
loading...
Comment Continued …
Subsequently we were contacted by Duff Johnson, CEO of Appligent Document Solutions and USA Chair of the PDF/UA standards group, who has pointed out that the PDFs we published are far from accessible and contained many ‘simple’ accessibility errors. Examples included:
• Table Structures – some were completed, many were missed
• Lists – many lists were not tagged correctly
• Image – the Creative Commons logo in the supplementary report did not have an image attribute, and
• Footnotes – some footnotes were out of order
At his own time and cost, Duff took the liberty of fixing our PDF files and asserted that it took his own folks 6 hours and 45 minutes to fix them. Duff invited us to re-publish the more accessible files on our website. In assessing the new PDF files provided by Duff, we asked Adobe to also provide their comments. After receiving the expert advice of both ...
... Duff and Adobe (Andrew Kirkpatrick) we are pleased to say that we have now published a more accessible set of PDF documents on our departmental website, finance.gov.au.
Our thanks go to Duff and his team for fixing our files and then offering them to us for re-posting.
We thought it important to share with you our list of the shortcomings in our process that includes, but is not limited to the following:
1. Basic and simple accessibility errors were made in the development of the files, these are not specific to PDF but are rudimentary accessibility issues representative of the common mistakes made by people who are new to accessibility. As an example, a suggestion for people creating table headings for a table in PDF is to search for basic advice, http://www.google.com/search?q=PDF+accessibility+table+headings provides an array of resources for this purpose.
2. Relying solely on the Adobe Acrobat Accessibility Check is not sufficient as it does not check all the elements required under WCAG. Using the “Full Check” in Adobe Acrobat Professional offers very limited validation and in fact the support documentation includes disclaimers making this point. As a result other tools should also be used to check for accessibility against WCAG 2.0; the Acrobat 9 Pro PDF accessibility repair workflow http://www.adobe.com/accessibility/products/acrobat/pdf/A9-pdf-access-repair-workflow.pdf is a resource that can assist designers and authors correct both list and table tags.
… more to come
loading...
Comment Continued …
3. The most current set of resources for the creation of accessible PDF through InDesign is http://www.adobe.com/accessibility/pdfs/accessibledocswithindesignCS4.pdf and http://tv.adobe.com/watch/accessibility-adobe/preparing-indesign-files-for-accessibility/, however we are also advised that to optimise the accessibility, further touch-up in Acrobat is required after exporting the file from InDesign. We’ve also been reminded of the importance of using the product and supplementary documentation produced by Adobe for their InDesign software.
4. Relying on Read out Loud to check accessibility is insufficient as Read Out Loud doesn’t deal with links.
It has been reiterated by Duff, that it takes ‘a LOT of education for a website developer to develop the knowledge and skills necessary to ensure that their HTML/CSS/JavaScript creations comply with WCAG 2.0’ but comparatively less time to produce an accessible PDF. We neither agree nor disagree, but we do suggest that knowledge of HTML accessibility concepts is a general pre-requisite ...
... skill for the effective and efficient production of more accessible PDF files.
A designer does not necessarily possess those skills and so additional educational material is required to support designers in the creation of more accessible documents, not only PDF ones. A point made in the conclusion of our Study.
During the course of our Study, we encountered several issues concerning the time it takes to produce a more accessible PDF document or to remediate one. As such, we were able to establish anecdotally that where creation is completed by experts (those well conversant with WCAG 2.0 and accessibility principles) it can be a relatively simple process with minimal resources deployed. However, where our test PDF documents had to be retrofitted for accessibility the time taken was considerably more than any government agency would consider acceptable or reasonable. Even the 6 hours and 45 minutes of remediation work on our ‘somewhat’ accessible PDFs, conducted by Duff and his team, would in reality be onerous for many departmental web teams. So the answer is better resources, better education and better checklists for everyone involved in the creation of accessible content, irrespective of its destination format. This should include instructions for authors, graphic designers, web publishers and development teams.
We stand duly corrected and offer the new accessibility ‘optimised’ PDF files for you to use as best practice examples of what might be achieved in accessibility of PDF files for government. View the new files online.
loading...
Would these new optimised pdf files satisfy as WCAG 2.0 compliant standalone files, ie not requiring a second format?
loading...
Hi Neil – no, they wouldn’t.
The reason for this is because the Portable Document Format doesn’t (currently) have any Sufficient Techniques to support a claim for WCAG 2.0 conformance.
As such, we put the reports in accessible HTML too.
loading...
Congratulations on taking on such a complicated task. It highlights the level of effort that we need to allocate to making PDFs more accessible.
loading...
I did not expect to be credited for the touch-up work performed on the Report’s PDF files – thank you for that.
I do want to point out that the time it took us to correct the originally-posted PDF files (6 hours, 45 minutes for 127 pages) needs to be understood in context – ie, compared to the time required to produce the alternative (HTML) versions of the two PDF documents comprising the Report.
My position: if departmental web teams were versed in the production of accessible PDF at the outset, then the time required to author the PDF would have amounted to the same time as required to make the InDesign file, plus (maybe) a couple of hours.
How does this compare to the time required to develop, text, check and post the HTML “equivalent”?
Secondly, I want to address Raven’s statement in her previous answer to this thread. As I pointed out ...
... in the review, the fact of the matter is that formal WCAG 2.0 Techniques are NOT required to comply with WCAG 2.0. The Australian Government may take a contrary position, but if they do, it’s not a position that’s consistent with WCAG 2.0.
Consider: no-one argues that DAISY files cannot comply with WCAG – of course they can – even though there are no Techniques (yet) for DAISY.
PDF files can and many do comply with WCAG 2.0. The WCAG Techniques publishing schedule does not define WCAG 2.0 conformance, and WCAG does not state or imply that it should.
Duff Johnson
loading...
HTML is looking good… :/
loading...
Hi All
The WCAG 2.0 Sufficient Techniques for PDF are now drafted and under review by the WCAG working group, with an early spring 2011 publication date expected. These guidelines can now be viewed at http://trace.wisc.edu/wcag_wiki/index.php?title=Category:PDF_Techniques Once these guidelines are published with you be changing your recommendation to allow PDF to be used without an alternative format being required?
Kind Regards
Kev
loading...
Please can you respond to my question and to the second question of Jennison Asuncion on the December 7, 2010 at 12:48 pm.
Eagerly awaiting your responses!
Regards
Kev
loading...
Hi Kev
We haven’t forgotten. There have only been two working days at Finance since you asked your question. Once the team is back at work, we’ll be sure to provide a response.
Regards
John
loading...
Hi Kev
The first conclusion of our Study states we have a need for:
“An updated position on the use of PDF files on government websites; including a review of the use of PDF files when the PDF/UA standard is released and Sufficient Techniques become available to satisfy WCAG 2.0 conformance”
So once Sufficient Techniques for PDF exist, we will review our policy. We need to ensure there are no qualifications made by the W3C before we make a commitment to endorse the format for use alone, as we will for similar formats.
Thanks
Raven
loading...
A thoroughly comprehensive review – my congratulations to AGIMO and Vision Australia. I must say that I don’t agree with the comment that the “issues contributing to the inaccessibility of PDF files, when used with assistive technologies, are not in general directly attributable to the Portable Document Format itself”. It seems to me that there are some issues that occur across assistive technologies – such as navigating by paragraph, navigating by heading and navigating by page number that are specifically an Adobe issue.
I have published a blog post of your findings here: http://www.gianwild.com/2010/12/31/between-a-rock-and-a-pdf/
loading...
Please see the following link for a detailed review and analysis of the AGIMO Report on PDF Accessibility.
http://www.appligent.com/talkingpdf-AGIMO-Report-Assessment
I’d like to extend thanks to the AGIMO staff for their graciousness and openness to this review.
Duff Johnson
Appligent Document Solutions
loading...
We welcome Duff’s review of our PDF Accessibility Study and note again Duff’s organisation assisted us with remediating our files to make them more accessible. However, we would like to clarify some issues raised in this review.
Our Study did not seek, nor intend to, assess or compare PDF with other formats. We’d welcome such a comparative study as it may lay to rest a number of the misconceptions around the accessibility of file formats. The User Consultation phase of our Study informed us that users themselves often provide the comparison to other formats (HTML, .doc, etc) and assert that they are more accessible, within a situation and context (see “Workaround Solutions” p.18 of our Report).
Duff also makes some valid points about the unknown and unquantified costs of creating a PDF file. We’d like this information too! Our own experience demonstrates that developing a fully accessible PDF ...
... file takes a lot of time, effort and therefore cost. Our Report’s conclusions highlight the need for ‘A study into the impact (cost and resource implications) in creating accessible PDF files’, indeed it would be excellent to have that for all file types. It would also be good if such a review included the tangible commercial costs of the software required to produce such files (e.g. OCR costs for scanned files).
Readers may be interested to know our policy and report are not a ‘self-fulfilling prophesy’. The Australian Government has always required accessible files from the outset of e-government (since 2000), irrespective of the format. This is in line with our legislative obligations to be non-discriminatory and ensure the widest possible access for everyone.
The Australian Government does not make assumptions about what document formats citizens need, we do public consultations that highlight that our citizens expect to have a choice. More importantly, under the UNCRPD, people have a right to receive information in a way that is accessible to them. Many government programs support this, as do recent judgements in other jurisdictions.
It is our prerogative to define what ‘Accessibility Support’ means in our jurisdiction, and within the Australian Government, agencies must use Sufficient Techniques to demonstrate their conformance to WCAG 2.0.
Many of Duff’s comments and recommendations are in-line with the overall findings of the Study, and our Web Accessibility National Transition Strategy addresses many of the conclusions (procurement, training, education etc). However, Duff’s proposed ‘Four Basic Policies’ need clarification:
1. We agree, see above comment on Sufficient Techniques.
2. The Australian Government takes a position of non-discrimination, i.e. a user should not have to complain about a file in order to obtain an accessible one, rather accessible information should be provided from the outset.
3. See point one.
4. As stated in the Report’s conclusion, the Australian Government will review the PDF/ UA once released.
Thanks for the post.
loading...
I called it a ‘self-fulfilling prophesy’ because the policy’s (unintended) effect is reduce incentives for software developers to improve their products and for users to learn better authoring practices. The predictable (and actual) result is reduced forward motion in accessibility technology and practice.
That’s why the current policy is hurting, and not helping the accessibility cause.
The history makes this clear. While PDF accessibility may still be regarded as mysterious in Australia, in (for example) the United States and Canada, government agencies and contractors have been creating (and fixing) accessible PDF files for years.
Australians are just as smart, and have access to the same software. The only significant difference is that in Australia there’s no policy to say that if you want to use PDF, it has to be an accessible PDF. As expected in such circumstances, few have bothered to learn how.
I agree that it’s the Australian Government’s role (not ...
... WCAG’s) to define what “Accessibility Support” means, and that Government may, if it chooses, follow only the published WCAG Techniques. My point in this regard was simply to point out that such Techniques are not required by WCAG 2.0 itself.
Regarding your point on the 2nd of my “Four Basic Polices”, you say…
—
2. The Australian Government takes a position of non-discrimination, i.e. a user should not have to complain about a file in order to obtain an accessible one, rather accessible information should be provided from the outset.
—
To which I reply:
Agreed, that’s covered in Policy 1. However, the fact is that mistakes and inadequacies occur regardless of format. Just as important as the commitment in Policy 1 to post accessible content is the commitment to correct content when an accessibility failure has been pointed out.
Thanks again,
Duff Johnson
loading...
Again, thanks for your comments Duff. We’ll keep all of the input from this blog in mind as the Web Accessibility National Transition Strategy progresses.
loading...
One of the main things I took from Duff’s review of the PDF report is that a blanket declaration that PDF is not accessible provides no incentive for developers to improve the accessibility of their PDFs. This is also my major concern with the recommendations coming out of the PDF study.
Many government department websites contained PDF documents in the WCAG 1.0 era when PDF was not acceptable (guideline 11) and frankly as we move into WCAG 2.0 I expect this will continue to be the case.
Of course I believe that HTML is the preferable format and should be used wherever possible. However at the same time, we need to recognise that many people will continue to use PDF (often badly) for a whole variety of reasons and we should do all we can to encourage them to make their PDFs accessible.
In my opinion we should adopt the technology ...
... neutral approach envisaged in WCAG2 and look at how a technology is used when determining if the content is accessible. I advocated this approach in a blog post in September 2009 http://www.dingoaccess.com/accessibility/wcag-20-and-accessibility-supported/ and in my CSUN 2010 presentation, “Ten Years of Web Content Accessibility Rules: Time for a Rethink?” http://www.dingoaccess.com/accessibility/wcag-rethink/
loading...
Judging from the above, the standards therefore indicate that a WORD version on its own on a website is not acceptable, but if we were to upload a WORD and a PDF of the document that would be fine?
Could you please confirm.
Thanks
Janet Kirkwood
Coordinator Online Services
Moreton Bay Region Council
loading...
The Australian Human Rights Commission published a media release in 2008 that described Word documents as an appropriate accessible equivalent for PDFs: http://www.hreoc.gov.au/about/media/media_releases/2008/86_08.htmlThis has widely been interpreted as meaning that the AHRC has deemed Word an “accessibility supported” technology. Of course, the Word document needs to be created in an accessible manner. I’ll be writing a blog post on this shortly.
loading...
Gian, Janet,
Of course, WCAG 2.0 wasn’t quite published when the Commission made this (unfortunate) statement, so they weren’t to know that the technology they were recommending didn’t have any Techniques…
Per Raven’s answer to Jennison on December 6 (see above)… no a Word file is unacceptable, regardless of how accessible you may think (and your organization may be willing to claim) it is. HOWEVER, Raven also seems to be saying (in her answer to Jennison’s item 6) that if you provide a PDF file AND some other format, even if there aren’t WCAG 2.0 Techniques for it, then you are OK.
But then I read the link Raven included, and it seems to say that you have to deliver a WCAG 2.0 compliant document.
It’s ironic that 2 1/2 years later, there still aren’t any WCAG Techniques for Word files – and PDF Techniques will probably arrive before those for Word.
So, it’s an ...
... interesting question. Does the AHRC still recommend Word files as an alternative to PDF files? If so, this seems in conflict with Australian government policy, which forbids (I guess) Word files unless an alternative format (with WCAG 2.0 Techniques) has been provided?
So… what IS the Australian policy? Must there be a WCAG 2.0 Techniques-conforming file, period, or (per Raven above), does the presence of a PDF file somehow create a special license to post some shabby Word or RTF file, per the AHRC statement?
Duff Johnson
Appligent Document Solutions
loading...
I won’t speak for Raven, but will give my opinion – as everybody else seems willing to do.
I’d suggest that any document published should be as accessible as possible, whether it’s a PDF or an Word or PDF file.
loading...
@Janet
WCAG 2.0 conformance is not about publishing in the required encoding formats.
WCAG 2.0 conformance is about structuring your content so that it is equally accessible to differently-abled people.
This means making sure it is EQUALLY Perceivable, Operable, Understandable and Robust, as defined in the guidelines.
If your documents are poorly designed and published as a Word document, a PDF and as HTML, you can still fail (spectacularly) to achieve WCAG 2.0 conformance.
It’s not about the file format, its about (deaf/blind/motor impaired etc) people being able to find, navigate through and understand published content.
It’s about presenting formats which are equally accessible to as many people as possible; and where something can’t be accessed by a particular user, ensuring an alternative is available for them that does (as close to) an equivalent job as possible.
loading...
This does bring to the fore some points which bear further examination.
Duff points out that it is not necessary for W3C to publish a Sufficient Technique for a technology in order for the use of that technology to be WCAG 2.0 compliant.
The AGIMO position (as published in the National Transition Strategy) is that “Where no WCAG 2.0 Sufficient Techniques exist to test the conformance of a technology or product, then WCAG 2.0 conformance cannot be claimed.”
…and that’s the definition by which we, Australian Government Agencies, (AGA) are bound.
This means we (AGA) are limited (by published policy) to those technologies that have published sufficient techniques.
The upside to this is that it presents (AGA) with a well defined set of choices. The downside is that we (AGA) may be deemed non-conformant by our own policy, whilst actually presenting (WCAG 2.0) conformant content. So be it. AGIMO is ...
... entrusted with ensuring a coherent path forward and in light of intelligent discussion will no doubt make amendments to policy in a disciplined and transparent manner.
That said, however, I point out again, that we need to be focussing on ACCESSIBILITY and not the STORAGE FORMAT.
loading...
Thanks to everybody for their valuable comments.
Dominic reminds us well of the point, it is not about the format it is about people who access government information in a variety of ways, irrespective of their ability or their method of access.
To clarify the position of the Australian Government for all, the current position is:
1. Australian Government agencies must conform to WCAG 2.0, as outlined in the Web Accessibility National Transition Strategy;
2. To prove conformance with WCAG 2.0, the Australian Government requires its agencies to use the ‘sufficient techniques’ provided by the WC3 to test for conformance, as this provides a standardised, reliable and repeatable way to test for conformance to WCAG 2.0.
a. Since many formats do not have enough ‘sufficient techniques’ to prove they conform to WCAG 2.0, they should not be relied upon (on their own);
b. An agency should not publish information in a single file format unless the chosen format ...
... complies with WCAG 2.0.
Pragmatically, we know that it will take time for Australian Government agencies to conform with WCAG 2.0. In complying with the obligation to be non-discriminatory and not disadvantage anyone in the meantime, AGIMO refers agencies to the World Wide Web Access: Disability Discrimination Advisory Notes that encourage Australian organisations to ‘publish in multiple accessible formats’.
While some might argue this strategy may impede progress, it’s designed to encourage greater digital participation, access to and use of Australian Government information for everyone.
loading...
Speaking as one of the participants in the WCAG WG for the development WCAG 2.0, I want to make some correction of the Accessibility team response on position 2 a & b.
“[2] a. Since many formats do not have enough ‘sufficient techniques’ to prove they conform to WCAG 2.0, they should not be relied upon (on their own);”
W3C WCAG WG wrote WCAG 2.0 sufficient techniques knowing that there is no way to document all sufficient techniques for ANY given technologies. Even W3C’s technologies specific techniques are not exhaustively documented. ARIA, for example, has only a handful of techniques documented. I am fairly sure even HTML is not fully documented. There’s no technology specific technique for video formats such as H.264 or any other formats in particular. The WCAG WG does not have the intention or resource to document all techniques for any technologies. We ...
... wrote WCAG 2.0 to encourage more innovation and creativity in accessibility and not to restrict what can or cannot be done. The sufficient techniques are meant to be examples. That is why they are not normative to WCAG 2.0. If an organization or a government is to restrict itself to WCAG 2.0 sufficient techniques, then it has misjudged W3C’s capacity and intention.
Position 2a is not the position that aligns with the nature of WCAG 2.0 sufficient techniques.
This is not the first time I see a government heading down this path. As a member of W3C WAI steering committee, I’d continue to encourage W3C to produce a policy guide to facilitate better policy adoption of WCAG 2.0.
“b. An agency should not publish information in a single file format … unless the chosen format complies with WCAG 2.0.”
File format cannot comply with WCAG 2.0. Only content can comply with WCAG 2.0. I know we want a simpler scenario in which we can be told which file format can and cannot be used. But the unfortunate truth is–the way to achieve accessibility is to use the appropriate technology correctly. As long is one does not invest in the effort to make content accessible, it really does not matter which file format is used. Take a less controversial format of txt file, for example. There isn’t much of any accessibility feature in txt format. There is no way to create accessible complex structures such as tables, labels, and such with txt files. But txt files are generally accessible if they are used to write a simple paragraph or two.
Position 2b is not valid.
That being said, WCAG WG created the concept of “Accessibility Support”. We understand that ATs are the other half of the equation. Technology developers can incorporate the most sophisticated accessibility features within its technology. But ATs need to advance alongside with new technologies in order to take advantage of the new development. We recognize that many people in underdeveloped countries do not have access to more expensive ATs. There are also languages without corresponding screen readers or braille devices. Therefore national policies or even enterprise policies need to take into account of what ATs are used in their environments in selecting the appropriate technology.
Therefore, it is valid to consider PDF and other technologies for whether they meet the bar of “Accessibility Support” in Australia.
From my fairly quick read of the study, I see that at least three of the examined ATs (JAWS, MAGic, and ZoomText) provide sufficient technical capability to interact with a PDF file. It is further estimated that these [AT] products are used by 89% of the assistive technology user population. The remaining 11% of the user population use AT that are partially or not sufficient.
While policy can take the view that we should not leave 11% of the population behind and, therefore, not use a technology that can otherwise be used by the other 89%, I think there could be a different policy would help those 11% without panelizing the 89%.
As noted in the executive summary, the primary issues, in the order of impact, are that PDF files are commonly not structured correctly for accessibility, some ATs are not adequate, and users are not familiar with how to use AT to access PDF files. These are the root causes of the problem. What if the Australian government adopts a policy that addresses the root cause of the problem instead of the symptom? I think it is more beneficial to all involved if there is a policy that:
1. Educate and encourages content creators to create PDF and other content correctly for accessibility (by meeting WCAG 2.0 success criteria).
2. Encourage AT advancement by assisting people with disabilities to differentiate and purchase the most advance AT so that they can take advantage of new technologies.
3. Encourage people to learn how to use their more advanced ATs with new technologies by deploying new technologies in ways that meets WCAG 2.0 and incentivizing continuous education for people with disabilities.
I think it would be a better policy to lift those who are left behind and make advancement in technology simultaneously. It is important to consider the long term implication of a policy—Does it encourage the government to produce more accessible content? Does it encourage technology companies to invest more on accessibility? Does it encourage AT products to compete? Does it panelize those who invested in better AT products? Does it encourage those who are using old or less competitive AT products to upgrade or switch? Does it encourage people with disabilities to do more with their AT products?
I suspect some people take issues with the recommendation because the study examined the facts, but does not provide a framework of how the policy recommendation would change stakeholder behavior in a positive way or the reason why the facts support its recommendation.
In short, I think there is some degree of miscommunication or misunderstand about WCAG 2.0 and further consideration and explanation about the recommendation is warranted.
loading...
The Australian Government position for web accessibility is one based in non-discrimination. It is not intended to limit innovation or efforts to be accessible. Instead it provides a realistic and flexible approach for agencies and ensures choice and improved access to information for users. As such, we require our agencies to apply WCAG 2.0, an internationally accepted guideline, to their websites in order to be as non-discriminatory as possible.
Within this jurisdiction we have both the authority and responsibility to impose rigour in the implementation of WCAG 2.0. We have elected to do this through the recognition of only Sufficient Techniques to claim conformance, as this indicates a technology’s capability to meet accessibility in a reliable, testable fashion.
The W3C note, regarding use of Sufficient Techniques, “If techniques are used other than those listed by the Working Group, then some other method for establishing the technique’s ability to ...
... meet the success criteria would be needed.” For many reasons, we have determined ‘other methods’ to be insufficient.
For the Australian Government, it matters only that web content and the technologies used to produce and publish it, whatever they may be, follow internationally recognised practices to achieve greater accessibility. We consider this position to be sound, flexible and focused on the needs of users.
I think you will find many of your recommendations are in fact recommendations of the study, not policy. Thank you for your comments Alex.
loading...
I’m going to touch on only a couple of points in response, then offer yet more unsolicited thoughts on policy.
You say…
“The Australian Government position… is not intended to limit innovation or efforts to be accessible.”
No-one is doubting the intent (nor has anyone suggested a bad intention). Nonetheless, the Government’s position can and does have precisely that limiting effect. Every expert who has weighed in on this question seems to agree with this claim. I have yet to read any explanation of how the policy does NOT, in fact, stifle innovation and education. The burden is very much on AGIMO to make this case, because so far, it’s only been asserted, not demonstrated.
You say…
“The W3C note regarding use of Sufficient Techniques, “If techniques are used other than those listed by the Working Group, then some other method for establishing the technique’s ability to … meet the success criteria would be needed.” ...
... For many reasons, we have determined ‘other methods’ to be insufficient.”
For now, I’ll just point out that if there are such reasons, they are not the subject of the recent Report.
You say…
For the Australian Government, it matters only that web content and the technologies used to produce and publish it, whatever they may be, follow internationally recognised practices to achieve greater accessibility. We consider this position to be sound, flexible and focused on the needs of users.
I’m afraid this position, as I previously stated, and as validated by Alex Li, is a fundamental mis-read of WCAG 2.0. As such, it is unlikely to have the effect of promoting conformance – it’s just as likely to cause agencies to publish less information online.
Here’s a policy to achieve WCAG 2.0 conformance which has a far greater chance of being “…sound, flexible and focused on the needs of users.”
1. Require WCAG 2.0 conformance of agencies.
2. Leave it up to each agency to understand WCAG 2.0 conformance in their own context (ie, don’t tell them how, simply require that they do it).
3. Require that they maintain documentation detailing how they achieve WCAG conformance in their internal workflows. If they want to use PDF – fine – they just have to be able to state their methods; their basis for asserting WCAG conformance.
4. Audit their workflows and documents as you see fit. Yes, there will be some leakers – there are today, there will be no matter what. This is NOT a “human rights problem” – don’t forget that even if your policy requires WCAG “sufficient techniques”, that doesn’t mean they’ll actually be followed in all cases. Users will still report problems that need to be addressed, Techniques or no Techniques.
Your current policy (presumably) already includes this audit process…
5. Crucially, make it easy for people to point out problems (whether they result from content failures or the user’s AT), and set performance standards for remediation.
(Surely this is the AHRC’s actual job, before they got into the software business?
)
So, hitting the buzz-words in order and from the top, my proposal is…
Realistic
(recognizes that people use a variety of formats)
Flexible
(Lets people use what they need to use)
Ensures choice
(Actually permits a choice)
Improves access
(Because AT users will get to use real documents, not an HTML facsimile or plain-text ‘shadow’)
Sound
(Because it’s market-based, inherently democratic and non-draconian)
Focussed on the needs of users
(Because it increases the likelihood that the content they encounter – from whatever source – is accessible. Plus, authors are “users” too, and they have to learn about accessibility, no matter what Techniques are required.)
Thanks,
Duff Johnson
Appligent Document Solutions
loading...
This blog is designed to foster open and transparent discussion, so thanks to everyone for their comments, questions and suggestions regarding web accessibility.
loading...
@Duff
I disagree.
Australian Government agencies can innovate as much as they want; it just has to occur alongside an alternative, WCAG 2.0 conformant, version.
And the conformant version must conform using sufficient techniques.
And the sufficient techniques must be the ones recorded by the W3C.
Sure, that last condition has been added by AGIMO.
Why add the burden of vetting and endorsing additional techniques?
There’s enough to do already.
As I noted in my previous post:
AGIMO is entrusted with ensuring a coherent path forward and in light of intelligent discussion will no doubt make amendments to policy in a disciplined and transparent manner.
AGIMO’s position is only binding on Australian Government agencies.
I believe the position taken is clear, and defensible.
Oh,yeah – that PDF plus one other format thing?
Sufficient Techniques for PDF are on their way.
That point will probably be moot before next year.
@Alex
The above reasoning applies to your discussion on “position 2a” in your comment, too.
Those ...
... with the responsibility for delivery must be granted the right to adopt appropriate strategies for obtaining measurable outcomes.
W3C WAI WCAG WG had the responsibility for defining conformance.
Others have the responsibility for delivering conformance.
“Position 2b” paraphrases the published AGIMO position.
If you examine Alternative Formats you will realise that whilst your point is valid, it doesn’t address the intent of the Alternative Format position.
Agencies must provide an additional alternative format, if the format they are using cannot demonstrate accessibility support.
This is also the position of WCAG 2.0
Perhaps this guidance would benefit from modification to “Agencies must provide an additional, accessible version, in an alternative format”, to drive the point home to those who (however inconceivable it may seem) have missed it.
At the heart of this though, is the AGIMO decision to go with the W3C-published sufficient techniques only, and not countenance those that require proof of sufficiency.
After reading all of the opinions above, I still think the AGIMO position to be one of pragmatic simplicity and efficacy.
loading...
Dominic,
You said:
Australian Government agencies can innovate as much as they want; it just has to occur alongside an alternative, WCAG 2.0 conformant, version.
You need to explain how (or why) such innovation will occur when there’s no value to it because the results are deemed unacceptable.
You said:
Why add the burden of vetting and endorsing additional techniques?
There’s enough to do already.
That would be an interesting question if the relative costs of the current policy vs. some alternative had been studied. Unfortunately, the AGIMO study on PDF specifically excluded such a comparison.
Perhaps more to the point… it’s really not about the burden of vetting techniques – that’s relatively trivial. especially given that most of the concepts are common to most electronic document technologies anyhow.
In any event, I thought the mandate was to maximize accessibility as a matter of respect for human rights, not to save a few dollars here or there!
“AGIMO’s position is ...
... only binding on Australian Government agencies.”
I know this. Am I supposed to be pleased because only Australians have to suffer the consequences of this policy? I’m not. I’m also not delighted at the prospect that the Australian government position may affect other governments.
You said:
Oh,yeah – that PDF plus one other format thing?
Sufficient Techniques for PDF are on their way.
That point will probably be moot before next year.
Techniques or no, the AGIMO study was unwilling to conclude (even though its data supports it) that there’s sufficient AT vendor support for PDF. Instead, the Report rates an otherwise acceptable and FREE screen-reader as insufficient due to a relatively minor software bug. So no… it won’t be moot.
Meanwhile, as a direct consequence of this policy, even when Techniques for PDF are available, few in Australia will have a clue how to implement them, because up until this point, accessibility is (effectively) a specialist activity limited to web content managers.
I’ll let Alex respond to your attempts to correct his understanding of WCAG 2.0 (if he feels like it).
You said:
After reading all of the opinions above, I still think the AGIMO position to be one of pragmatic simplicity and efficacy.
Let’s just explore one plausible scenario that highlights how the AGIMO position has a pernicious effect.
An agency is choosing between two vendors for a large contract to provide insurance benefits management services. Part of the work involves delivering millions of benefits statements, terms and conditions, etc, etc. to policy-holders.
Vendor (a) has done a lot of work on accessibility, and has a benefits-statement generating system that produces tagged PDF files. They claim WCAG 2.0 conformance, and are prepared to demonstrate how they meet the Guidelines.
Vendor (b) has done nothing on accessibility. To win the contract, however, they are willing to modify their report generation system so that it spews out plain-text streams. No lists or tables or watermarks or pagination, etc. – just 67,000 words of plain text for each benefits statement. Possessed of “Sufficient Techniques” yes, but in reality, an extremely poor reading experience.
Australian government policy clearly requires hiring vendor (b).
Does that outcome seem like it fosters innovation or improves service to end-users? Of course not. It’s an own-goal, pure and simple.
loading...
Vendor (b) would not be chosen. Under current requirements both vendors would fail accessibility requirements. Plain text is not an alternative to complex content.
loading...
Gian,
Could you be specific? What is the “current requirement” that would prohibit using vendor (b)?
If the vendor is delivering plain text using WCAG 2.0 techniques alongside PDFs, then they satisfy the Australian government requirements, no? If there are other requirements besides WCAG 2.0 conformance, where can I read about them?
If you wish to claim that plain text is inadequate in this instance, you’ve placed the Government in the position of vetting documents for “complexity”, not simply conformance with WCAG 2.0. I’m guessing this is not exactly what the Government has in mind.
Duff Johnson
Appligent Document Solutions
http://www.appligent.com
loading...
Vendor(b) would patently not be able to comply with success criterion 1.3.1 – Information and relationships. If the content contained complex information such as tables, then it would also need to use table headers, captions and summaries. How can you do that in a text document?
loading...
A while ago, I prepared three simple PDFs under different conditions to see to what extent the information they contained could be accessed by screen readers – see Are These PDFs Accessible for more information. Please note, the intention of the exercise was not to show how to make perfectly accessible PDFs, but to see if it was possible to make a PDF that is sufficiently accessible by just following basic good practices when preparing a Word document. The feedback I have got on the site and by direct email suggests that with a few minor caveats it is possible. I would greatly appreciate more screen reader users testing the different PDFs and providing feedback.
loading...
It’s possible that in the robust discussion on PDFs, their attraction and the difficulties in making them accessible, we’re losing sight of the main issues.
The first (it seems to me) is that we’re trying to provide accessible information to as wide an audience as possible. To this end, AGIMO is providing advice to people in the government sphere on how best to do this. There’s nothing wrong with innovation – as long as we don’t leave people behind.
The second issue (and one that the experts from across the water may not appreciate) is that there is a legislative requirement to provide accessible websites, and a person who feels that an Australian website (whether in the government or the private sector) is not accessible may complain to the Australian Human Rights Commission.
In their latest advice (October 2010), the AHRC says “organisations that publish documents only in PDF risk ...
... complaint under the DDA unless they make the content available in at least one additional format and in a manner that incorporates principles of accessible document design.”
So, it would appear that AGIMO is acting in accordance with AHRC in taking its current stance.
loading...
Kerry,
My point is that the current Australian government policy inhibits innovation in accessibility technologies.
While I’m indeed “across the water”, I appreciate (and respect) the requirement for accessible websites – never otherwise. We’ve had a similar requirement for US Government websites (albeit not WCAG 2.0-specific) since 2001.
Duff.
loading...
… and your point is an assertion, not a fact.
I don’t see any sign of a slackening of use of PDF as a result of the latest AGIMO advice. I believe that Web managers will continue to publish PDFs, because they provide a useful way of getting certain material online.
I also believe that the current round of discussions are raising the profile of Accessibility, and that’s a good thing. And we can do with all the publicity and education that can be provided by Adobe and AGIMO.
loading...
Having gone through the extensive appendices, I have pulled out the PDF test results by assistive technology. As you can see from the results, most errors occur across assistive technology, which indicates to me that it is a problem with Adobe Acrobat and not the particular assistive technology.
http://www.gianwild.com/2010/12/31/pdf-test-results-by-assistive-technology/
loading...
Gian,
Thanks for your post. I want to correct a number of significant misperceptions. Each of the points you make highlights a problem with authoring practices and/or AT, not with PDF and not with Adobe (or other) PDF readers.
Page numbers. First, page numbers in PDF files may be accessed (and used for navigation) by any AT that can use a PDF reader. At the present point in time it is clumsy – I’ll grant – because it involves interacting with the reader’s toolbar (via the PC cursor in JAWS, for example), but it works.
Page numbers do not correspond with “Adobe Page Navigation toolbar”. This is an authoring issue, pure and simple. The page-number displayed on the PDF page may readily be set to correspond with the page-number as displayed in the toolbar. InDesign (among other authoring applications) automatically sets the PageLabel value to match the printed page number when the PDF ...
... is generated. The AGIMO report itself is an instance in which this happens correctly.
As I highlighted in my review of the Report, the PDF file which presented problems in terms of page-number-based navigation was a “full spread” in which two “logical” pages appear on a single PDF page. This is done for printing purposes – such files are inappropriate for distribution. This PDF should not have been included in the study at all – indeed, its inclusion caused a serious distortion in both the data and the Report’s analysis.
Table headers. There’s little evidence of problems with table headers in the study. If users expect or prefer AT to impose enumeration on un-numbered table rows, then make a feature-request to the AT developers. It has nothing to do with the PDF or the PDF Reader.
Form-fields. There’s no evidence of problems with form-fields in PDF technology. To the extent that issues were noted at all, they are matters for document authors and AT developers.
PDF-unaware AT. Likewise, for many of the AT applications you mentioned (PAC Mate, VoiceOver, Read Out Loud, Read & Write Gold and Dragon Professional) – their issues have nothing to do with PDF or Reader – these technologies simply don’t support accessible PDF. Call your AT vendor!
Overall
Your assumption that if a problem is commonly reported then it must have PDF or PDF readers at its origin has no basis in the Report’s data. Instead, you are highlighting that which the Study already made clear:
1) Most users don’t know how to author documents in an accessible manner (regardless of format).
2) AT support for PDF is less from ideal.
Please note that the Report itself states (page 38, “Satisfaction Ratings”, second paragraph) that “Participants were generally satisfied with their use of the [properly tagged] documents and indicated they would be very comfortable in using PDF documents like these again.”
Duff Johnson
Appligent Document Solutions
http://www.appligent.com
loading...
When Microsoft asked their customers what new features they wanted in Word, the customers came back with many suggestions for features that were already in Word. Did Microsoft say “well, it’s there- find it if you can” – no, they modified their program.
This is what I want Adobe to do. It is not enough to say that it is all about the authoring practices – if authoring a PDF is so complex (and it is, because I’ve tagged many) then it is up to Adobe to streamline this process.
As for assistive technologies, once again I think it is up to Adobe to deal with this issue. If they want assistive technologies to interpret PDF then maybe they should start funding some of the more popular assistive technologies to do this. Assistive technology developers have very little money, and I think it is extraordinarily unfair to blame this on them, ...
... when they have done their utmost to make things accessible.
By the way, the assistive technology results came straight from the AGIMO study.
loading...
Gian,
I’m not disputing that Adobe (and other PDF software vendors) could do more – they certainly could. So could every software vendor. As of right now, for example, MS Word is incapable of setting table row headers!
My point was simply to offer some facts regarding the origin of the problems in the cases you mentioned. You speculated that the issues were a function of PDF itself or Adobe software, and this is simply not the case.
Secondly, as you know, authoring accessible PDF is 95%+ identical to authoring an accessible Word file. So if Microsoft made it easier to structure Word files correctly (they could do a LOT more too), then that ease can (and does) translate directly into the PDFs created from Word using either Microsoft or Adobe software.
How do you know that Adobe does not help fund AT development?
I’m not “blaming” the AT vendors – I’m ...
... simply stating facts. AT vendors have to choose to support tagged PDF – no-one else can choose it for them.
On the text-example from the other comment (since there are no more “replies” available on that thread) – I guess I wasn’t being clear.
Stipulate that the text content is such that WCAG 2.0 Techniques for plain text are applicable (ie, there are no tables). I assume that in such a case the Government would go with vendor (b), not the vendor who’s done all the work to ensure accessible PDF.
Duff Johnson
Appligent Document Solutions
loading...
Gian,
There are a lot of claims in your comment that are not backed up.
1) You suggest that Microsoft talks to their customers and fixes the issues that are requested, and that Adobe does not. Do you believe that Microsoft fixes every issue that customers identify? I know that we do talk with our customers, lots of them. I also know that it is true that there are improvements that can be made and these are continually being examined and evaluated against other priorities. Sometimes accessibility rises to the top in those examinations, sometimes not.
2) “They should start funding some of the more popular assistive technologies”
As Duff pointed out, how do you know that we aren’t? As it happens, we have done some of this, including providing support for NVAccess which helped them improve their support for PDF to the point that it passes ...
... every test that it could (but still receives a rating of only “partially sufficient”).
3) “Assistive technology developers have very little money, and I think it is extraordinarily unfair to blame this on them, … when they have done their utmost to make things accessible.”
The AT vendors are not receiving “blame” here. I’m not sure what data you have about AT company financials or how you know that they have all “done their utmost” – these sound good and help you make your point, but aren’t based on verifiable facts.
The fact (from the report) that the AT vendors themselves rate their PDF support as equivalent to HTML (JAWS, NVDA, SATOGO, ZoomText, MAGic) or “providing most of the functionality available for HTML” (Window-Eyes) suggests that what they are hearing from their customers is that they are generally happy with their abilities to use PDF documents. This matches the comment from the report that “Participants were generally satisfied with their use of the Collection A [correctly authored] documents and indicated they would be very comfortable in using PDF documents like these again.”
loading...
Hi everyone, thanks for your comments. We normally close comments on posts after a month or so, but in this case a longer time was provided. We appreciate your feedback and will use your input where appropriate going forward with AGIMO’s accessibility work.
Cheers
Kayelle Wiltshire
Acting First Assistant Secretary
Agency Services Division
loading...