Web Accessibility from PDFs and Apps to Project Planning: A conversation with Derek Featherstone

On November 20, Systemscope co-hosted a talk with Simply Accessible’s Derek Featherstone about accessibility and usability in light of the fast-approaching July 2013 TBS Web Standards on accessibility and usability compliance deadlines.  Shortly after the talk, I met with Derek to go over some pressing topics our attendees had that we didn’t have time cover at the event:

  1. PDFs and Accessibility
  2. Meeting GC Web Standards Deadlines
  3. The Best of All Possible Worlds
  4. Testing for Accessibility

1. PDFs and Accessibility

What’s your take on making PDFs accessible?

PDFs are often published in that format because it is convenient for the publisher more so than the person getting the information.  The first question to ask is whether the content should be published in a PDF format or not?

If the decision to publish in a PDF format has been made already and it’s a standard operating procedure, what can be done to make the PDF accessible?

For a report, a strategy for dealing with publishing to PDF is to publish the report from pieces that are initially accessible, instead of trying to convert a PDF to its HTML equivalent. An accessible PDF can be just as accessible as HTML.

Some things to consider for building accessible PDFs:

  • Build the report using an accessible Word template
  • Make sure the reading order is right and that all the image assets have alternative text
  • When creating big reports that are built in Word and merged with Excel tables, make sure there’s an accessible baseline or template that exists.

Is it possible to retrofit PDFs and make them accessible after they’ve been produced?

You can take the PDF that’s produced and fix it, which can be very time consuming if you’re not a PDF accessibility expert.

To retrofit PDF format documents you can go back to the source document and once you make the source document accessible, you can regenerate the PDF as an accessible PDF. This can be efficient because it then becomes reusable. You can also employ a service from PDF accessibility experts to fix up your PDFs.

Overall, spending money to retrofit PDFs after they have been published is one-time money spending.  Creating PDFs from accessible templates that have been built before publishing to PDF gives you a multi-use accessible production baseline.  The money invested upfront to create those templates can be more effectively spent than spending time and money retrofitting PDF documents. Of course, this really does vary depending on how complex your PDFs are. In some cases it might be just as cost effective to have them converted to accessible PDFs by a 3rd party.

(^top)

2. Meeting GC Web Standards Deadlines

With the compliance deadlines looming, are there any other pragmatic takeaways you can offer Government of Canada web professionals who are now racing against the clock to meet the standards?

Any takeaway depends on the types of work you’re dealing with.

For document-centric accessibility work:

  • Start by checking the overall structure and making sure there is a page structure that exists. Whether it’s in PDF or HTML format, there should be properly tagged headings, lists, paragraphs and alternative text for images.
  • If your documents are not interactive, i.e. forms, and your accessibility compliance tasks centre around content, check image assets that are included to make they are located in the right place on the page.   For example, check that an image at the top of the page is not related to a paragraph at the bottom of the document.

For web applications-centric accessibility work:

  • Deal with your most important assets first by asking if this is a mission-critical application that has to be made accessible.  For example, at the Canada Revenue Agency, a payroll calculator is an employment-related application that everybody needs and that is central to the CRA’s service offerings.
  • If your application is a map, try to understand who is using the map and for what purpose.  Too often, web accessibility is reduced to blind people who need to ‘hear’ the application to use it.  If, however, the mapping tool is one that requires the user to draw a map to then calculate the area, accessibility moves beyond blind people using the application to people who might need a keyboard accessible way to ‘draw’ the map.  Other people might be using voice recognition software to use the application.  The understanding around web accessibility has to move beyond blind people to understanding different interfaces for different users.

In many cases, when attempting to retrofit applications, it becomes obvious that the wrong tool was purchased to accomplish the task. That’s when usability testing and understanding user needs and tasks is critical to accessibility.

(^top)


3. The Best of All Possible Worlds

What would be an ideal Government of Canada scenario in terms of web accessibility for you?

When we work on large-scale accessibility projects, we try to cover off five pillars:

  1. Planning
  2. Procurement
  3. Professional development
  4. Process
  5. Policies

These pillars are not sequential, but they have to exist.  From a process sense, you need to make sure your entire software development lifecycle takes into account the needs of people with disabilities from design to testing to roll-out.

From a procurement standpoint, we would ideally have the proper tools that are accessible in the first place.  For service procurement, requirements have to have accessibility built into the final deliverable.  Sometimes, vendors will say that a tool or piece of software is accessible, only for clients to find out that it hasn’t been tested appropriately or evaluated properly for all dimensions of accessibility. Other times, vendors will understand document-centric accessibility but not web application accessibility.

We often get called in to evaluate third party work to assess whether the tools or applications that have been delivered meet people’s accessibility needs and standards.  We work as an advocate for the client since they might not know or have the time to understand all the dimensions of web accessibility.

(^top)

4. Testing for Accessibility

Is it possible to do accessibility tests in-house rather than post-purchase or pre-launch?

A good place to start is with the WCAG checklist and being to understand how to interpret it.  The expertise to interpret the checklist takes years to develop, but there are W3C resources on WCAG out there with techniques on how to test accessibility and usability and why it’s important.  Often for clients though, it’s easier to get somebody else to come in and assess the work for you.

How is that important to an enterprise-level project?

If you’re not making professional development and continuous improvement part of an overall program to achieve accessibility and treating it as a one-time project, the work won’t be sustainable.  Training on accessibility, whether from a technical, compliance or user experience dimension gives you a base that goes beyond a one-time project.

When we give training sessions to various clients, whether they are designers, quality assurance staff or testers, we offer an initial assessment of their project and how to fix it.  More importantly, we help them fix it and teach them how to avoid the issue in the future.  Knowing how to avoid issues and fix problems takes accessibility out of project mode into a built-in process that’s part of a bigger program.

Embarking on a redesign takes years to accomplish instead of fixing other more basic problems on a day-to-day basis.  Compliance to these new standards should be a starting point, not an end point.  Executing these compliance standards is the beginning, not the end.  Accessibility and usability should be part of a continuous, iterative process, not a one-time annual project.

With that, our conversation came to a close.  In sum, with a fast approaching compliance deadline, well-planned, prioritized efforts to meet accessibility will enhance usability while also realizing operational efficiency and improving overall user experience.

(^top)

If you are interested in attending future Systemscope Lounge talks about the Government of Canada web presence, please contact Denise Eisner (eisner@systemscope.com) to be included on the mailing list. We appreciate all inquiries, but preference is given to Government of Canada professionals.


Kellen is a dynamic consultant, who excels at analysing how people, information and technology work together. As Director of Government Service Excellence, Kellen is focused on helping the Government of Canada solve the complex problems related to serving Canadians. This is done with a focus on effective and strategic use of the web, integrating with other channels such as telephone, in-person, social media and mobile platforms. His strength is bringing clarity to complex situations, and Kellen achieves this through his skills in facilitation, change management, process design and creative problem solving.


Comments:


Leave us a comment: * Your information is never shared