Sunday, March 06, 2011
AChecker Web Accessibility and Code Checker
By default the software tests against WCAG 2.0 (Level Double A). There are options for WCAG 1.0 and for Level Triple A. Also BITV 1.0 (Level 2) and Section 508 Stanca Act.
Code validation checks are optional for HTML and CSS.
Tuesday, November 16, 2010
More than PDF needed for accessibility
My view is that while in theory PDF could be made accessible, but in practice this is so hard to do it is not worth the trouble. It is simpler to create an accessible web page with HTML. Ideally a good quality HTML page can replace PDF.
Gian started with an introduction to web accessibility issues. She pointed out that WCAG 2 guidelines do not cover cognitive disabilities (including dyslexia, aphasia). Also colour blindness is common. Few people are completely blind (that is not being able to see any light). Many use magnifiers to make the text larger. Also "screen readers" do not cope well with Flash and JavaScript. She showed an example of text transposed to demonstrate what a person with dyslexia is faced with. She pointed out that physical disabilities have difficulties with keyboards and/or mice.
Gian pointed out that Youtube now has automated text captioning. The creator uploads a file of the text and Youtube automatically matches this to the audio.
Gian the went on to discuss the Disability Discrimination ACT and the precedent set by the SOCOG case I was an expert witness for. The Australian Human Rights Commission recommends WCAG version 1 (version 2 to follow). Federal agencies are required to comply with WCAG version 1 now with version 2 to follow. The Australian Human Rights Commission gets more complaints about PDF than any other format.
There were 40 submissions to the AGIMO PDF review. Vision Australia found tagged PDF difficult to use and lacking in support from assistive technology. AGMIO looked at best practice advice from Adobe. Assistive technology vendors advised they were reluctant to support tagged PDF as so people use it. As a result AGIMO will not define as accessible and will require an alternative format.
However, tagging is useful, as for example for text to speech. What Gian seemed to be saying was that a simple text PDF document was easier to navigate than a complicated web site with lots of menus. However, a simple web page might be even better.
Gian demonstrated to use of a text to speech system (in this case BrowseAloud.com). She pointed out that these systems can be useful for people who have a physical disability as they can place the pointer over some text to be read without having to click. One feature of the software is a dictionary. It occurs to me that some of these features and guidelines could be of value to students, particularly with those learning in a second language.
Gian suggested that AGIMO and other governments should fund an accessibility toolkit for WCAG 2, to translate the esoteric language of the guideline into something web designers can understand and use. Gian also pointed out that many simple accessibility tips (such as "use simple language") in WCAG 1 was removed from WCAG 2. These sort of useful tips could be included in a government sponsored cookbook.
One interesting option I suggest is the use of e-book formats. These could provide a useful alternative to PDF for large government reports. The EPUB e-book format is based on HTML. It should therefore be possbible to create an e-book which looks good online, prints like a conventiaonal report and could be easily also provided as an accessible web site. This would remove the need for PDF and web versions.
ps: The meeting was at the Geoscience Austrlaia building in Symonston. This is worth a visit just for the display on geology in the foyer, the library, map shop and cafe.
Thursday, November 04, 2010
PDFs and accessibility of government information
At the previous WSG Meeting, an AGIMO representative expressed the view that it was not feasible to make PDF, RTF or MS Word files accessible and so agencies should provide information as accessible web pages. That statement (which I support) appears to have pre-empted the formal release of the AGIMO PDF Accessibility Review, which was due to report in mid-2010 (and is now four months late). This would not be a great change from the current formal AGMIO advice: "Agencies are reminded that it is still a requirement to publish an alternative to all PDF documents (preferably in HTML)."
My suggestion would be to make corporate reports available in EPUB e-book format and the same content as ordinary web pages. Corporate types would see "e-book" as being a trendy new thing they could read on their iPads. Most people would read the same content as ordinary web pages.
November 2010 Canberra WSG meeting
Date: Tuesday 16 November, 2010
Time: 3.00pm - 4.30pm ...
Cost: Free
Follow @wsgcanberra on twitter
Topic 1: PDFs and accessibility - AGIMO review
PDFs have always been an issue when it comes to accessibility. With the advent of WCAG2, it becomes the decision of policy-makers such as AGIMO and the Australian Human Rights Commission (formerly HREOC) as to whether PDFs are deemed an 'accessible technology' and whether they can be on a site without an accessible alternative. AGIMO is currently undertaking a review of PDFs and their capacity to be made accessible. This seminar talks about the review and its likely outcomes.
About the presenter
Gian Wild has worked in the accessibility industry since 1998 and consulted on the development of the first Level AAA accessible web site in Australia (Disability Information Victoria). She ran the accessibility consultancy PurpleTop from 2000 to 2005 and built the accessibility tool, PurpleCop. Amongst other sites, Gian has worked as the Accessibility Consultant for the Melbourne 2006 Commonwealth Games and was responsible for training Microsoft developers in accessibility. She also wrote the original and updated version of the Victorian eGovernment Resource Centre Web Accessibility Toolkit. Gian was a Member of the W3C Web Content Accessibility Guidelines Working Group from May 2000 to August 2006.
Wednesday, May 19, 2010
Removing Validation Errors from Google Blogger With HTML 5
I changed to a new version of Blogger recently, which may have been a
mistake. I assumed by now that Google would be generating HTML code
without errors in it. But when I replaced my hacked template with one of
Google's new ones, instead of dozens of errors, I got hundreds.
After looking at some articles on the topic, the way to avoid validation
errors seems to be to avoid Google generated code. So I cut away most of
the Google template.
At the same time I thought I would try out HTML 5. This seems to reduce
the amount of custom code Blogger generates for fixing idiosyncrasies in
particular browsers and so reduces the amount of code with validation
errors in it.
does not seem to be finding as many errors as the I am not sure if less code is being generated because HTML 5 is a better standard, more standardised browsers have been created, or so few are using it the problems have not yet been found. Also the HTML5 validationXHTML one, perhaps because HTML 5 is less rigid in its syntax, because the checker is better (not finding spurious errors) or is worse (not finding real errors).
Apart from HTML validation, there are still problems with my blog for CSS validation and Mobile compatibility (the blog only scores 64% for Mobile Web compatibility). Some of these I can't fix, such as Blooger inserting a style sheet with an error in it and settings in the HTTP header. Perhaps it is time to change to a more standards compliant blog system.
Friday, October 24, 2008
Making web sites for a mobile devices and people with disabilities
Contents
- Perceivable
- Information conveyed solely with color
- Large pages or large images
- Multimedia with no captions
- Audio-only prompts (beeps) for important information (warnings, errors)
- Embedded non-text objects (images, sound, video) with no text alternative
- Important information in non-text content (images, multimedia)
- Free-text entry (for example, alphabetical characters allowed in numeric fields)
- Content formatted using tables or CSS, and reading order not correct when linearized (for example when CSS or tables not rendered)
- Information conveyed only using CSS (visual formatting)
- Operable
- Understandable
- Robust
Monday, June 23, 2008
UK Government fails own web accessibility guidelines
The COI has set a minimum standard of accessibility for new UK public sector websites at Level Double-A of the W3C Web Content Accessibility Guidelines . This is required as of December 2009 for central government departments and March 2011 for central government executive agencies and non-departmental public bodies.
The COI suggests using free and commercially available automated testing tools as part of measuring accessibility. However, applying one such test, the Web Accessibility Test (TAW), the COI's page failed with eight level 2 problems (excerpt of the report appended). This indicates that the page does not meet at Level Double-A of the W3C Web Content Accessibility Guidelines. The problems with the page are minor and easily corrected.
The COI's help page, states that the "... website's objective are to conform to the Guidelines for UK government websites, which support the W3C's Web Content Accessibility Guidelines 1.0, Level AA, to ensure a Web accessibility standard have been achieved and are maintained." The statement is misleading, as it suggests the web site meets Level Double-A, when it does not. Also the statement does not use the wording suggested in COI's own policy document.
In contrast the Australian Government accessibility policy requires a lower level of compliance, to Level A of the W3C guidelines. The web page from the Australian Government Information Management Office (Australian equivalent to UK COI) stating this requirement not only meets this requirement, but exceeds it, passing the more stringent automated Level Double-A test (excerpt appended), which the UK COI failed.
UK Government Web Page Test
TAW 3.0 (6/24/08 1:11 AM) Validation conform to WAI guidelines, W3C Recommendation 5 May 1999Testing outcome: http://www.coi.gov.uk/guidance.php?page=131
Test summary outcome Automatic Human review Priority 1 0
49
Priority 2 8
37
Priority 3 Not analysed Accesskey links: Skip navigation | Home page | Site map | Search this site | Frequently Asked Questions | Help for site | Feedback | Accesskeys
In Delivering inclusive websites:
- Background
- > Minimum standard of accessibility <
- Planning
- Procurement
- Measuring accessibility
- User profiles
- Assistive technology
- Content design
In Accessibility, usability and design:
Delivering inclusive websites
Web standards & guidelines
Delivering inclusive websites
Minimum standard of accessibility
Minimum standard of accessibility
- The minimum standard of accessibility for all public sector websites is Level Double-A of the W3C Web Content Accessibility Guidelines. All new websites must conform to these guidelines from the point of publication.
- Websites owned by central government departments must be Double-A conformant by December 2009. This includes websites due to converge on Directgov or BusinessLink, unless convergence is scheduled before this date.
- Websites owned by central government executive agencies and non-departmental public bodies must conform by March 2011.
- Government websites owners are reminded to follow the conditions of use for a .gov.uk name (Registering .gov.uk domain names (TG114)). Websites which fail to meet the .gov.uk accessibility requirements may be at risk of having their domain name withdrawn.
- At the time of writing, version 1.0 of the Web Content Accessibility Guidelines is the current standard for web accessibility. At such time that version 2.0 becomes a W3C Recommendation, this policy will be reviewed within six months. Consideration will be given to the adoption of version 2.0 as the minimum standard for public sector websites.
Content formats not covered by WCAG 1.0
- Content formats not covered by version 1.0 of the Web Content Accessibility Guidelines (e.g. Flash, PDF, JavaScript etc) should only be used if it is determined that they are the most appropriate for the intended purpose. For example, this could be where the proposed content enhances the functionality or understanding for the intended audience.
- Every attempt should be made to ensure that the accessibility features of the relevant authoring tool are used.
- In all cases, web content must always be developed according to the process set out in your website accessibility policy.
This page was printed from the COI website at 00:11 on Tuesday, 24 Jun 2008. It is subject to © Crown Copyright.
From: TAW 3.0 Validation Testing outcome for http://www.coi.gov.uk/guidance.php?page=131, to WAI guidelines, W3C Recommendation 5 May 1999, as at 6/24/08Found issues: ...
[WAI] Priority 2 accessibility issues. A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. 8 automatically detected problems and 37 problems that require human review have been found.
3.5 Use header elements to convey document structure and use them according to specification.
Verify that all headers are properly marked up ("h1"-"h6" elements).
- Improper header nesting: Header levels must not increase by more than one level per heading. Do not use headings to create font effects; use style sheets to change font styles (1)
Line 32:
11.2 Avoid deprecated features of W3C technologies.
- This HTML element uses deprecated attributes. (7)
Line 19:
Line 38:
Line 38:
Line 38:
Line 49:
Line 54:
Line 55:
...
Australian Government Web Page Test
TAW 3.0 (6/24/08 1:25 AM) Validation conform to WAI guidelines, W3C Recommendation 5 May 1999Testing outcome: http://webpublishing.agimo.gov.au/Accessibility
Test summary outcome Automatic Human review Priority 1 0
30
Priority 2 0
37
Priority 3 Not analysed ![]()
Browse
Location: Home > Accessibility and Equity > Accessibility
Accessibility
Accessibility is a general term used to describe the degree to which a system is usable by as many people as possible without modification. Web pages often have access issues for people with disabilities or with technological constraints.
Australian Government departments and agencies are also required to maximise their use of new technologies by ensuring that their websites address access and equity issues for people from culturally and linguistically diverse backgrounds.
Tell Me About?
The Australian Government aims to achieve fairer and more accessible government services and programs through its Access and Equity Strategy. The strategy seeks to promote fairness and responsiveness in the design, delivery, monitoring and evaluation of government services in a culturally diverse society.
The Government's Access and Equity Strategy is guided by the Access and Equity Framework (Department of Immigration and Citizenship) formerly known as the Accessible Government Services for All Framework. It was developed in 2006 in consultation with Australian Government agencies, taking into account their ability to contribute both as separate portfolios and to whole-of government responses to the challenges faced by our culturally diverse nation.
Its four principles, and the corresponding performance indicators, address key responsibilities of government:
- Responsiveness – Extent to which programs and services are accessible, fair and responsive to the individual needs of clients
- Communication – Open and effective channels of communication with all stakeholders
- Accountability – Effective and transparent reporting and review mechanisms
- Leadership – A whole of government approach to management of issues arising from Australia’s culturally and linguistically diverse society.
The framework suggests strategies for the implementation of these principles. It aims to assist agencies to analyse their performance and better share good practice responses to challenges and opportunities.
Progress in implementing the Access and Equity Strategy is published in the Access and Equity Annual Reports (Department of Immigration and Citizenship).
Why Must I?
Under the Disability Discrimination Act 1992 agencies must ensure that people with disabilities have the same fundamental rights to access information as the rest of the community.
World Wide Web Access: Disability Discrimination Act Advisory Notes (Human Rights and Equal Opportunity Commission)
Under the Commonwealth Disability Strategy, (Department of Families, Housing, Community Services and Indigenous Affairs) Australian Government agencies are obligated to remove barriers which prevent people with disabilities from having access to their policies, programs and services.
Under the 2000 Government Online Strategy departments and agencies are required to comply with the Web Content Accessibility Guidelines 1.0 (World Wide Web Consortium).
Agencies must achieve level "A" conformance (all Priority 1 checkpoints are satisfied), and it is recommended that agencies achieve level "AA" conformance (all Priority 1 and Priority 2 checkpoints are satisfied).
The W3C guidelines explain how to make web content accessible to people with disabilities. However, following them will also make web content more available to all users. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.
The Web Content Accessibility Guidelines
The W3C guidelines provide a series of checkpoints that can be used to ensure that websites are accessible. Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.
Priority 1
W3C states that a web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
Level of Compliance: The Human Rights and Equal Opportunity Commission's view is that compliance with the W3C WCAG 1.0 guidelines to the Single-A level is a minimum rather than a desirable outcome. Websites that demonstrate such compliance may still be difficult or impossible to access for many users with a disability.
Priority 2
W3C states that a web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
Priority 3
W3C states that a web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.
How Do I?
The Human Rights and Equal Opportunity Commission provides information on World Wide Web Accessibility standards, guidelines, tools and techniques.
Government resources
- Access and Equity Issues for Websites (AGIMO, Better Practice Checklist)
- Better Information and Communication Practices (Department of Families, Housing, Community Services and Indigenous Affairs)
Good Practice Guide for Culturally Responsive Government Services [PDF, 146KB] (Department of Immigration and Multicultural Affairs)
Other resources
- Core Techniques for Web Content Accessibility Guidelines 1.0 (World Wide Web Consortium)
- Web Accessibility Initiative (World Wide Web Consortium)
- Web Content Accessibility Guidelines 1.0 (World Wide Web Consortium)
Who Can Help?
A list of workshops and training is available from HREOC - World Wide Web Accessibility.
For queries and assistance contact Human Rights and Equal Opportunity Commission -
disabdis@humanrights.gov.au.
For further details regarding access and equity requirements, contact:
Multicultural Affairs Branch
Department of Immigration and Citizenshipaccess&equity@immi.gov.au
What's Related?
Colour Theme Changer
colour theme:
Change the site's colour theme to blue
Change the site's colour theme to green
Change the site's colour theme to red
Legal Notices
- privacy
- disclaimer
- copyright © 2008 Commonwealth of Australia
...
From: TAW 3.0 ValidationTesting outcome for http://webpublishing.agimo.gov.au/Accessibility
conform to WAI guidelines, W3C Recommendation 5 May 1999, 6/24/08 1:25 AM
---