Content:
Archive for the ‘Accessibility’ Category
AGIMO has released ‘Web Accessibility National Transition Strategy’
On the 30th June 2010, AGIMO released the ‘Web Accessibility National Transition Strategy‘. This details exactly how all Government agencies should prepare for, and implement, the second version of the W3C Web Content Accessibility Guidelines.
Compliance requirements
All web sites and web content must meet compliance requirements:
- WCAG2, Level A by December 2012
- WCAG2, Level AA by December 2014
With one exception: web sites and web content created before July 2010 that will be archived or decommissioned before December 2012 are not required to meet WCAG2.
Who does this apply to?
The Online and Communications Council requires all federal, state and territory websites to conform to the guidelines to meet Single A level within a two-year period (by the end of 2012). By the end of 2014, all these web sites should be Double A compliant.
Three phase approach
Preparation phase: July – December 2010
- Agency website stocktake: archiving and decommissioning non-essential and out-dated information and compiling a list of websites and web services to be upgraded.
- WCAG2 conformance check: assessment of in-scope web sites for current level of WCAG compliance via self-assessment or independent assessment.
- Website infrastructure assessment: assessment of third party products (such as Content Management Systems, e-commerce systems etc.) for WCAG2 compliance.
- Capability assessment: identify knowledge gaps within the organisation and identify specific WCAG2 training needs.
- Risk assessment: undertake a risk assessment of current WCAG2 conformance levels of sites, number of sites and infrastructure and skill capabilities.
- Mitigation projects led by AGIMO: Projects or working groups created to address areas of non-conformance across agencies, such as mapping interfaces.
Transition phase: January – December 2011
- Training and education: WCAG2 training, perhaps provided by AGIMO.
- Procurement review: assessment of all procurement policies to ensure they include accessibility criteria.
- Infrastructure and capability upgrades: upgrading of infrastructure to meet WCAG2 requirements.
- Progress reporting: AGIMO to maintain oversight of WCAG2 conformance by agencies.
Implementation phase: December 2012 (Level A), December 2014 (Level AA)
- Agency implementation: implementation of WCAG2 requirements, focusing on: common issues and fail points; priority of implementation; and a web accessibility action plan.
- Conformance testing: self-assessment or independent assessment of an agency’s web sites
Federal agencies will be required to provide conformance reports to AGIMO, which may be subject to independent evaluation.
The following information on an agency’s web site should always be up-to-date and compliant with WCAG2:
- contact details;
- information about the organisation, including its role, legislation, administered functions, structure, key personnel and services;
- current information that will help citizens to understand their responsibilities, obligations, rights and entitlements (benefits, etc.) in relation to government assistance;
- current public notices, warnings and advice.
Updates to the eGovernment Accessibility Toolkit
Last year I updated the eGovernment Accessibility Toolkit. Newly released in HTML are:
A few problems with the concept of accessible PDFs, Part Two
Firstly, apologies for such a long delay between posts – especially on a topic that garnered such interest!
This is part two of a review of the Accessibility Support Documentation for PDF. Reading through the document is quite reassuring, with every single success criterion (even the AAA ones) either supported by Adobe, or the responsibility of the document author.
It’s only when one reads the Appendices that it becomes apparent that all is not as it seems. Adobe PDF does fail in some serious ways, it just seems to have escaped the author of the Accessibility Support document.
But firstly, I looked at the lack of testing, and make sure you read the comments because there is one from Adobe!
Secondly, let’s look at the document in more detail.
Correctly tagged headings
In response to WCAG2 Success Criterion 1.3.1: Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text, (Level A). Adobe says:
“PDF provides a variety of ways to convey information and relationships with semantic elements such as headings, lists, tables, and paragraphs. The ISO 32000-1 PDF Specification details structure types in section 14.8.4.
Testing results
- Test id 4 (Correctly tagged paragraphs)
- Test id 5 (Correctly tagged headings)
- Test id 6 (Correctly tagged controls and input elements)”
However, if one actually reads Test id 4, 5 and 6 in the Appendices, it actually turns out that Window Eyes does not read headings. In fact, if you don’t believe me, read the Appendices, and I quote:
“Headings are identified. (WE [Window Eyes] does not identify headers but does read text)”
Headings are extremely important to screen reader users. It allows them to scan a document to determine which section they need to read. And this is especially important in PDF documents, because PDF documents tend to be much longer than your average web page – that’s a lot of text to trawl through if you can’t jump from heading to heading.
You know, headings are so important that they are mentioned at WCAG2 Level A twice. Success Criterion 2.4.1: Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages, also requires headings, so that screen reader users can jump from one place to another. Adobe says:
“PDF allows documents to be tagged with headings which can be used in conjunction with assistive technologies to bypass sections of content. PDF also provides bookmarking functionality that allows keyboard users to accomplish similar bypassing.
Testing results
- Test id 9 (Correctly tagged headings)
- Test id 10 (PDF bookmarks)”
Once again, if one reads test id 9 and 10 in the Appendices, it turns out that Window Eyes does not read headings, but it does read bookmarks. So, instead of using headings to break up your PDF you could use bookmarks, but then a review of the Appendices shows that JAWS doesn’t read bookmarks. Now this is a real problem. It means you need to markup every heading in your PDF twice: once as a heading (so JAWS will read it), and once as a bookmark (so WindowEyes will read it). And remember, I talked about the scarcity of testing previously, so there could be assistive technology out there that reads neither.
A few more accessibility concerns…
- The abbreviation feature is not supported by the magnifier ZoomText.
- You can embed media, but there is no equivalent of the HTML NOEMBED feature. This means users cannot set an alternative for any media they embed in the PDF.
- You can only adjust the primary background colour of the PDF – not the background colour of regions of a page.
My conclusions
PDF is not an accessible technology… yet. I do commend Adobe for being one of the first companies to address accessibility issues in their products, however they still have a long way to go to match the accessibility features of X/HTML. The difficulty in tagging a PDF also essentially prohibits accessible PDFs from being developed in the mainstream media.
A few problems with the concept of accessible PDFs
I was recently asked my thoughts on the Accessibility Support Documentation for PDF. Reading through the document is quite reassuring, with every single success criterion (even the AAA ones) either supported by Adobe, or the responsibility of the document author.
It’s only when one reads the Appendices that it becomes apparent that all is not as it seems. Adobe PDF does fail in some serious ways, it just seems to have escaped the author of the Accessibility Support document.
But firstly, let’s look at the actual testing undertaken.
Testing was incomplete
Testing was conducted on the following:
- Windows XP, JAWS 9, IE 7
- Windows XP, JAWS 9, FF 3
- Windows XP, WindowEyes 7, IE 7
- Windows XP, WindowEyes 7, FF 3
- Windows XP, Zoom Text 9, IE 7
- Windows XP, Zoom Text 9, FF 3
What about other operating systems?
It all seems a little Windows-centric doesn’t it? What about Mac users? In fact the Mac operating system has a very large range of assistive technologies and is often used by people with disabilities in preference to Windows.
What about other browsers?
IE 7 and FF 3 are not the only browsers out there. There’s other versions of these products and there’s Safari, Opera and Chrome. And that’s just the popular browsers.
What about other assistive technologies?
JAWS and WindowEyes are not the only screen readers around. What about NVDA, BrowseAloud and the Apple’s inbuilt screen reader? What about Read Out Loud- Adobe’s inbuilt screen reader? And testing on only one version of each assistive technology seems short-sighted in the least.
What about other disabilities?
This is my biggest concern, and I’ve left it to last. What about other assistive technologies that are for people with disabilities other than those with vision impairments? It is generally accepted that PDFs can be used by vision impaired users, but they are not the only people with disabilities out there. Firstly, PDF was not tested with other assistive technologies such as an onscreen keyboard, joystick, touchscreen or thumb switch (and that’s only some of the other assistive technologies out there). Secondly, from the testing that was conducted, it seems that the success criterion were not reviewed in relation to how they affected other people with disabilities, such as cognitive disabilities (the largest group of people with disabilities on the web), physical disabilities and hearing impairments.
In the next post
In the next post I will be talking about exactly why PDF isn’t as accessible as HTML, and which success criteria in WCAG2 PDF does not meet.
Why I’m sticking with WCAG1… for now
There has been much chatter since AGIMO released a statement that they were endorsing WCAG2. A few clients have asked me whether now is the right time to move to WCAG2. My belief is that the time is not right… yet.
The Disability Discrimination Act still requires compliance to WCAG1
Legally, we are required to follow the requirements of the Australian Human Rights Commission (AHRC), Disability Discrimination Act (DDA). The DDA recommends compliance to WCAG1, Level AA. It may be some time before the AHRC endorses WCAG2.
The Whole of Victorian Government Web Standard requires compliance to WCAG1
For Victorian Government departments and agencies, web sites fall under the Whole of Victorian Government Web Standard. This Web Standard requires compliance to WCAG1, Level AA.
AGIMO is still to release an implementation document on WCAG2
In stating that AGIMO will release an implementation document, they are indicating that further information needs to be provided to the web community on exactly how to comply with WCAG2. Hopefully, it will answer some pertinent questions such as:
- Is it necessary for pages to validate?
- Are there any advisory techniques we should follow? (for example, to assist people with cognitive disabilities – a group under-represented in WCAG1 and WCAG2)
- Are tables for layout acceptable?
AGIMO and the AHRC have to make some policy decisions regarding WCAG2
WCAG2 requires policy makers such as AGIMO and AHRC to decide on the suitability of certain technologies such as PDFs, JavaScript, Flash and Java. Neither AGIMO nor the AHRC have released any information on this.
Compliance with WCAG2 will not be required until December 2012
(And according to the Mayan calendar we’ll all be dead by then…)
Sites will not need to be compliant with WCAG2 for almost three years. Thus sites can remain compliant to WCAG1 until then. This gives companies time to fully assess WCAG2 and how it will affect their web site, as well as providing time for AGIMO and the AHRC to make some policy decisions.
A WCAG1 compliant site is accessible to people with disabilities
WCAG2 has only recently been released and there has not been much testing to ensure that it fully addresses issues of people with disabilities (such as people with cognitive disabilities). WCAG1 is 11 years old, and although it has its problems, it is a proven method to ensuring the accessibility of a web site.
In conclusion…
This is my current advice to my clients, who have their own specific set of circumstances. I will, in the near future, start recommending the use of WCAG2. However at this stage I do not believe there is enough information available to support developers in complying with WCAG2.
Twitter and accessibility
For more information see the eGovernment Accessibility Toolkit on Twitter and accessibility.
Facebook and accessibility
For more information see the eGovernment Toolkit on Facebook and accessibility.
Accessibility presentation – WCAG2
I ran a short presentation on WCAG2 on the 17th December in Brisbane for the Computer Human Interaction Special Interest Group (CHISIG). This was the same presentation that I ran for Web Directions South 2009 in Sydney a few months ago.
For more information see the CHISIG Events website or listen to the WCAG2 presentation.
Website Redesign conference
I’ve just finished running a short presentation on the accessibility of social networking tools for the Website Redesign conference in Melbourne, 7- 8th December.
I mentioned my work on the eGovernment Accessibility Toolkit, and the Web Manager’s checklist and Web Developer’s checklist.
Introduction to accessibility
Videos
Koorie film with audio descriptions
Flash
Indonesian learning activity transcript
PDFs
eGovernment Accessibility Toolkit
Web 2.0 technologies
Making Links conference
I’ve just run a short workshop at the Making Links conference in 2009. I went through the Office for Disability factsheet for Web Managers; specifically how to test a web site for accessibility compliance. The document, Web Manager’s Checklist, is one of a series of factsheets that I developed for the Office for Disability and spoke about at a Victoria Online seminar.
