Search:

Content:

Archive for the ‘Accessibility’ Category

Prioritising web accessibility in the build of a web site

I just spoke at DrupalGov last week about Prioritising web accessibility in the build of a web site. Feel free to download the slides. There are three formats (please note only the Word file is fully accessible):

Assistance to victims of the Queensland floods

In Australia we have all been devastated by the flooding across our country (and the fires in Western Australia). If you have money to spare, please give generously at the Queensland Government site. If you can volunteer – and we will all need volunteers for some time to come, go to the Emergency Volunteering site. You can help pets and animals or provide a bed.

If you are a Government providing web services about the floods

If you are a Government department, agency or charity (QLD, NSW or Victoria) providing web services about the flooding, then I can provide accessibility testing of the relevant flood-related pages or web sites, free-of-charge.

Please use the contact form to request assistance and I will contact you to discuss your accessibility needs.

Results of assistive technologies tested against Adobe Test Suite

The information in this post was taken from The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability. See my previous blog posts for the conclusions of the AGIMO study into PDFs.

Summary results for assistive technologies tested against Adobe Test Suite

The following is the assistive technology, followed by the tests supported, divided by the number of tests completed:

  • JAWS 8 & 9 – 43/43 (all)
  • NVDA 2009.1 – 41/43
  • SATAGO 3.0 – 36/42
  • VoiceOver 10.5 & 10.6 –  9/43
  • WindowEyes 7 – 36/43
  • ZoomText 8 & 9 – 21/21 (all)

Thus only the following assistive technologies completed all the tasks in the Adobe Test Suite:

NVDA 2009.1 Adobe Test Suite failures

  • Non English phrases
  • Non English document

SATAGO 3.0 Adobe Test Suite Failures

  • Paragraphs (partially supported)
  • Skipping via headings (partially supported)
  • Detectable page number (could not test)
  • Non English phrases
  • Non English document
  • Name, value and role (comments)
  • Name, value and role (headings)
  • Name, value and role (lists)

VoiceOver 10.5 & 10.6 Adobe Test Suite Failures

  • Image alt
  • Label, value and state (text field)
  • Skipping via headings
  • Labelled text field controls
  • Bookmarks
  • Tabbing
  • Visible focus
  • Non English phrases
  • Non English document
  • Control retains focus
  • Input error is identified in text
  • Name, role and value (table)
  • Name, role and value (buttons)
  • Name, role and value (checkbox)
  • Name, role and value (combo box)
  • Name, role and value (list box)
  • Name, role and value (radio buttons)
  • Name, role and value (text fields)
  • Name, role and value (links)
  • Name, role and value (comments)
  • Name, role and value (headings)
  • Name, role and value (lists)

Window Eyes 7 Adobe Test Suite Failures

  • Skipping via headings
  • Non English phrases
  • Non English document
  • Name, role and value (headings)
  • Name, role and value (lists)

PDF test results by assistive technology

The information in this post was taken from The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability. See my previous blog posts for the conclusions of the AGIMO study into PDFs.

Several issues occurred across assistive technologies (as well as with Read Out Loud and the keyboard only feature), which leads me to believe that there are still a few bugs in the Adobe interface:

  • Page number not read aloud (JAWS 9 & 10, NVDA 2009.1, Window Eyes 7, Read Out Loud, Keyboard only)
  • Page number of document does not correspond with Adobe Page Navigation toolbar (JAWS 9 & 10, MAGic 10, ZoomText 9.14, Read Out Loud, Keyboard only, Auslan)
  • Difficulty with table headers (JAWS 9 & 10, NVDA 2009.1, SATAGO 3.0, Window Eyes 7, ZoomText 9.14, Keyboard only)
  • Difficulty with form fields (JAWS 9 & 10, NVDA 2009.1, SATAGO 3.0, Window Eyes 7, MAGic 10, Read Out Loud, Read & Write Gold 9, Dragon Professional 10.1, OS configuration

PAC Mate

No tasks could be completed.

Voice Over

No tasks could be completed.

JAWS 9 & 10 (results extrapolated to version 11 & 12)

  • Page number in document is not read aloud by JAWS
  • Page number of document does not correspond with Adobe Page Navigation toolbar
  • Users expected table rows for ‘item details’ to be numbered
  • ‘Page Down’ does not act as user expects
  • Cannot manually enter information into date field with ‘auto forms mode’ in JAWS 10 turned on
  • Cannot jump between paragraphs using JAWS
  • User does not know JAWS table navigation commands
  • User does not know how to navigate via headings
  • User does not know how to search for a page using Adobe Page Navigation toolbar
  • User tries to use Word commands
  • User found it hard to use drop down calendar picker

NVDA 2009.1

  • Page number in document is not read aloud by NVDA 2009.1
  • ‘Page Down’ does not act as user expects
  • NVDA 2009.1 does not provide a direct association between the header and data cells
  • Field name (postal code) is not read out
  • User does not know how to search for a page

SATAGO 3.0

  • User expected table rows for ‘item details’ to be numbered
  • SATAGO 3.0 was unable to load document
  • Edit field name not read aloud when arrowed to

Window Eyes 7

  • Page number in document is not read aloud by Window Eyes 7
  • Window Eyes 7 does not accurately associate table containing 2 rows of headers
  • Headings not identified by Window Eyes 7
  • User has to exit ‘Browse on’ mode to read non editable fields
  • User did not know that Window Eyes 7 does not identify headings
  • User did not know how to navigate table
  • Not able to search by page number

MAGic 10

  • Page number of document does not correspond with the Adobe Page Navigation toolbar
  • Hover reading function does not work within content area of document
  • Arrowing down functionality not efficient
  • Field name is not read out for postal code field

ZoomText 9.14

  • Page number of document does not correspond with the Adobe Page Navigation toolbar
  • ‘Doc Reader’ reads all table cells as one
  • Quality of content poor when magnified
  • Background colours still do not provide sufficient contrast when inverted, making text hard to read
  • Table header information not very clear when colour inverted by user
  • Two column presentation requires horizontal scrolling to read

Read Out Loud (Adobe Reader 9)

  • Page number in document is not read out loud
  • Page number of document does not correspond with the Adobe Page Navigation toolbar
  • All of first page is read as one block
  • Text entered into form fields not automatically read out

Read & Write Gold 9

  • Text entered into form fields not automatically read out

Dragon Professional 10.1

  • General Dragon commands do not work
  • Dragon does not apply form field numbering overlay for PDF forms
  • Text input is not as accurately recorded in PDF documents as it is with other application

Keyboard only

  • Page number of document does not correspond with the Adobe Page Navigation toolbar
  • User reads left column first but information starts on right
  • Table headers not visible when using the Reflow feature in Adobe Reader
  • Page numbers not visible when using the Reflow feature in Adobe Reader
  • User is not aware of the Reflow feature in Adobe Reader

Operating System (OS) configuration

  • OS colours not inherited by form fields in document
  • Colours specified in OS not inherited in document
  • Adobe Reader customisation settings not intuitive

Auslan

  • Page number of document does not correspond with the Adobe Page Navigation toolbar

Between a rock and a PDF

PDFs and Accessibility Seminar

I will be running a public seminar on accessibility and PDFs in Melbourne on January 18th. For more information see the Melbourne Web Accessibility Meetup Group.

The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability

I have finally had a chance to read through the extensive AGIMO study into PDFs. It’s a comprehensive review of PDFs and their accessibility, and the authors should be commended for completing such detailed testing while still being able to explain the findings in plain English. It is the most thorough review of PDFs that I have seen, and it confirms some of my previous statements.

I recommend that you read the report, even if you don’t have time for all the supplementary documentation.

This post will be dealing with the conclusions of the report. A future post will discuss the assistive technology testing in more detail.

Conclusions

The study focussed on PDF files, as more complaints are lodged with the Australian Human Rights Commission about PDF than any other format.

“Overall, the Study found that there is insufficient evidence to establish that the development of the Portable Document Format and improvements in assistive technologies have advanced enough for PDF files to be considered accessible for people with a disability, particularly for those who are blind or have low vision.” (quoted from the Executive Summary).

The study discussed three important issues that contributed to the inaccessibility of PDFs (quoted from the Executive Summary):

  • the design of the PDF file by the document author to incorporate the correct presentation, structure, tags and elements that maximise accessibility;
  • the technical ability of the assistive technology to interact with the PDF file (via the relevant PDF Reader); and
  • the skill of the user and their familiarity with using their assistive technology to interact with a PDF file.

The study also mentioned that there is no agreed definition as to an “accessible PDF”, although some work in this area is being undertaken.

In conclusion:

“Until further data is available on the characteristics of an accessible PDF file and there are Sufficient Techniques available to support the conformance of the PDF technology to WCAG 2.0, the Australian Government position recommending that alternative file formats be provided whenever PDF files are used should remain unchanged.”  (quoted from the Executive Summary).

Australian Human Rights Commission updates their Web Advisory Notes

The Australian Human Rights Commission have updated their Disability Discrimination Act: Web Advisory Notes. There are a lot of changes, the most important being of course, the endorsement of the W3C Web Content Accessibility Guidelines, Version 2.0. However there are many other interesting additions. All quotes are directly from the updated Disability Discrimination Act: Web Advisory Notes. All emphasis is mine.

Accessibility is needed throughout the design of a site

“… creating accessible web content should be an integral part of the web design cycle, and accessibility features should be incorporated into all aspects of the design process.”

United Nations Conventions on the Rights of Persons with Disabilities

“While the Australian Government has primary responsibility for meeting Australia’s obligations under the Convention, all sections of society, including industry, educational institutions, and community organisations, must play an active role in upholding the rights established by the Convention. Accordingly, any failure to provide full access to the web and other internet-based technologies for people with a disability may be seen as a violation of human rights.”

Encouraging the use of multiple formats

“There are wide variations in the accessibility of different file formats, and some formats are generally considered to be more suited to a particular type of content than others. Feedback that the Commission has received from users and web accessibility experts suggests

that traditional HTML is the most universally accessible format. Other formats have advantages and disadvantages that should be considered when deciding which format to use. For example, the RTF format is considered to be more generic, but it is less suited than Microsoft Office Word to representing complex tables so that they can be navigated successfully by screen-reading software. In general, material will be accessible to the greatest number of users when it is published in multiple accessible formats.”

Documents that cannot be made accessible

“It should also be borne in mind that some content cannot be made accessible online to some people with a disability, especially if it is inherently graphical in nature. Organisations that make such content available online need to consider strategies for making it accessible, for example, by providing text descriptions of pictorial content, or using qualified contractors to produce tactual maps and diagrams on request.”

PDFs

“The Commission’s advice, current October 2010, is therefore that PDF cannot be regarded as a sufficiently accessible format to provide a user experience for a person with a disability that is equivalent to that available to a person without a disability, and which is also equivalent to that obtained from using the document marked up in traditional HTML.”

“The Commission will review the accessibility of PDF documents again in 2013, by which time it is expected that the provision, support, and utilisation of accessibility features will have improved.”

Document security

“Some file formats provide mechanisms for enhancing the security of documents by preventing unauthorised editing, copying, or printing. Some of these mechanisms are not compatible with accessibility for people with a disability, and document authors should ensure that security features do not prevent access to the document by assistive technology.”

“If there are concerns about ensuring the authenticity of material published on the web in multiple formats, then a statement should be included that specifies which format is to be regarded as definitive or authorised, and noting that additional formats are being provided to maximise access.”

People with cognitive disabilities

“It should be emphasised, however, that accessibility of web content cannot always be achieved solely through compliance with WCAG 2.0. In addition to these Guidelines, web designers and authors will need to make themselves familiar with a range of tools, resources, and emerging best-practice solutions, as they meet their accessibility goals and responsibilities under the DDA and the Convention. This is particularly the case in areas that are not comprehensively addressed in WCAG 2.0, such as the needs of people with cognitive disabilities.

The role of the accessibility specialist

“The Commission strongly encourages web designers to use expert advice and information that is up to date with web content publishing and access challenges and solutions. A number of Australian companies and organisations provide consultancy and design services with specialisation in accessibility. There is currently no national accreditation system for expertise in this area, so potential clients of such services should use standard assessment practices such as speaking with referees and examining samples of their work.

Ten common web accessibility failures

  1. “Failure to include appropriate text descriptions (such as “alt-text” labels) for images;
  2. Failure to provide accessible alternatives when using a visual CAPTCHA;
  3. Failure to use technologies (such as Flash and JavaScript) in ways that are accessible;
  4. Failure to use HTML features appropriately to indicate content structure such as the hierarchy of headings;
  5. Failure to explicitly associate form input controls with their labels;
  6. Failure to ensure sufficient difference between foreground (text) colour and background colour;
  7. Failure to identify data tables with Summary or Caption, and failure to mark-up data tables correctly;
  8. Failure to provide a way for users to disable content such as advertisements from flashing rapidly (rapidly-flashing content may cause seizures in susceptible individuals), and failure to provide a way for users to stop a page from auto-refreshing;
  9. Failure to ensure that web pages can be used from the keyboard (that is, without the mouse);
  10. Failure to alert the user to changes on a web page that are triggered automatically when selecting items from a dropdown menu.”

Gian Wild is offering a “Ten common failures” review for web sites that want an overall picture of their accessibility compliance.

Transitioning to WCAG2 – Government

“All Australian government websites should comply with the timelines and conformance requirements of the NTS, whether or not they are specifically mandated to do so. In particular, state and territory governments are strongly encouraged to comply with the AA conformance level that applies to Commonwealth Government websites.

Transitioning to WCAG2 – non-Government web sites

  • “Non-government websites and web resources whose development commences after July 1 2010 should comply with WCAG 2.0 to a minimum of AA-Level conformance;
  • Existing non-government websites or web resources that undergo substantial change in the period July 2010 – December 2013 should comply with WCAG 2.0 to a minimum level of AA conformance;
  • All existing non-government websites and web content should comply with WCAG 2.0 to a minimum level of AA conformance by December 31 2013.”

Accessibility supported technologies

“WCAG 2.0 does not provide a list of accessibility supported technologies, since such a list is likely to require regular updating and is likely to have local variation. The Commission will be working with the Australian Government Information Management Office (AGIMO) and other stakeholders to develop more detailed advice about technologies (and features of technologies) that are considered to be accessibility supported in the Australian context.”

“Until such advice is available, web developers should give serious consideration to using those technologies that are known to be compatible with WCAG 1.0. In cases where this is not practical, they should seek expert accessibility advice before using other technologies.”

Limits on obligation to comply with the DDA: Web Advisory Notes

“The advice provided in these notes is intended to give effect to the requirement of the DDA for access to be provided without unreasonable barriers that exclude or disadvantage people with disability. In some (but not all) circumstances, obligations under the DDA to provide equal access are limited by the concept of unjustifiable hardship.”

“Where issues of unjustifiable hardship have to be decided, section 11 of the DDA requires the courts to consider all relevant circumstances of the case, including:

  • The nature of the benefit or detriment likely to accrue, or be suffered by, any persons concerned;
  • The effect of the disability of a person concerned;
  • The financial circumstances, and the estimated amount of expenditure required to be made, by the person claiming unjustifiable hardship
  • The availability of financial and other assistance to the person claiming unjustifiable hardship; and
  • In the case of the provision of services, or the making available of facilities—any relevant action plans given to the Commission under section 64 of the DDA.”

Gian Wild endorses BrowseAloud

I am pleased to announce that I have just signed on with BrowseAloud to become an official reseller in Australia. As some of you may be aware, I have a special interest in cognitive disability accessibility, and BrowseAloud is a fantastic assistive technology aimed at such users. It can be implemented on any web site – and can be useful to people with disabilities even if your site doesn’t fully meet WCAG1 or WCAG2. Please contact me if you would like more information or you would like a free trial. You can also download BrowseAloud and use it on my site.

About BrowseAloud

BrowseAloud is an assistive technology that is free for the end user (another reason why I like it!). Websites pay a fee to enable BrowseAloud for users of their site. BrowseAloud is aimed at people with cognitive disabilities, mild to moderate vision impairments, people with low literacy and people with English as a Second Language.

Cognitive disabilities and vision impairments in Australia

  • 4 million people with a registered disability
  • 2 million people with dyslexia or specific learning difficulties
  • 300,000 people who have a mild visual impairment

Low literacy and ESL in Australia

  • 6.2 million adults have low literacy levels
  • 3 million people with English as a foreign language

BrowseAloud features

BrowseAloud has some very nifty features.

Hover highlighting

Text on the site can be read aloud simply by hovering over it. This screen reader is great for people with visual impairments that can see the text, but cannot read it. This is also great for people with physical disabilities, as they do not need to “click” using their specific assistive technology (joystick, switch etc) to read the text aloud. Words are highlighted as they are spoken which provides audio/visual reinforcement that improves word recognition and comprehension for people with English as a Second Language and people with low literacy levels.

Text selection

Users can select specific text that they want read aloud.

Translator

BrowseAloud can translate English, French, German, Italian and Spanish. Translations are read aloud in the corresponding languages. This is a great feature for people with English as a Second Language, or when learning a second language in improving word recognition, pronunciation and comprehension.

Dictionary

The user can look up accurate definitions from an updated database of words and definitions. Both website owners and users can add words and definitions to this dictionary for their own website. Check BrowseAloud and how it speaks my name, “Gian”. That’s the correct pronunciation: I added it to BrowseAloud myself!

Screen masking

Users can alter the appearance of the screen by adding a combination of different colour filters to filter the entire screen (excluding the current sentence or word). This is great for people with attention deficit disorders and can be used in conjunction with the screen reader.

MP3 maker

Website owners can make MP3 files to host and stream directly from their website. Website visitors can convert any online text to MP3 and listen on the move.

Screen magnifier

Users can magnify any text on the site. Magnified text can appear as a ticker across the top of the page, or appear word by word at the top of the page.

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.

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!

Th is

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.