Category Archives: Accessibility

Why your PDF should be HTML

Over the last few months the issue of formats has come up a few times, when librarians, educators and marketeers have all wanted to use PDFs to deliver information to the user. I thought now would be an opportune time for me to state why, in many cases this is a bad idea (even if done with the best of intentions).

What the experts say

Jakob Nielsen’s Alertbox, July 14, 2003 – PDF: Unfit for Human Consumption
Usability guru Jakob Neilsen is forthright in his appraisal of PDF as a format on web sites.

Joe Clark’s 2005 article about PDF accessibility included here to refer to the section where Joe clearly elucidates why most things should be HTML and even better has written a thorough list of exceptions. If your information doesn’t fall into one of these categories then you really should be using HTML.

Where we are going wrong

Of the many PDFs that are currently available on our various web sites very few can really justify the format that they are in if we use the criteria laid out in the articles linked to previously. I believe that a combination of overstating the role of a particular visual style and understating the inconvenience to the user leads to a situation where uploading a document suffices. I don’t believe this is the case. If we want to provide the best experience for users then we need to be making that extra (small) effort to put the information in the right format. It’s not that hard, and everyone benefits.

Issues with ISSUU

A beta subject guides page has been created by the proactive librarians that we have at Glamorgan that uses issuu.com , a service for hosting PDFs that wraps them up in flash, and add various user interface feature like page turning animations, zooming, various views and useful social features like commenting and sharing. I think it’s unfortunate that the useful features have been mingled with the user interface fluff that actually makes the information harder to retrieve.

Putting it into practice

To show what’s possible I downloaded a PDF of Lighting Design and Technology & Live Event Technology from a Subject guides page, and spent an hour or two copying and pasting to create an HTML version. The pdf is 115k to download. The HTML is 41.5k. In addition to the smaller file size the user does not need to wait for the PDF reader to open up, can navigate via a table of contents and most usefully can click on the many URLs to go straight to the info. The HTML format enables to the user to directly interact rather than read, then copy the links.

It may not have the visual impact of the issuu PDF version, but it is more functional, in the browser window that people are used to. Also, none of this precludes making the pdf available for those people that wish to download it.

Summary

Hope that people find this a useful position statement, and would love to see some response in the comments.

Click where?

When placing hyperlinks on a site, there can be a temptation to use ‘click here’ as the link text, assuming that the context of a link is immediately apparent.

The rest of this article contains some help and advice on this issue.

One of the issues that we face as developers of various CMS is what to do when the people writing the content write in a way that is contrary to the WCAG. Point 6.1 of the guidelines explains, in a rather technical way, the problem. For a more informal discussion and some real world examples I’ve linked to the article why ‘click here’ is bad practice.

I’ve selected a few highlights from the page –

“Click here” is device-dependent. There are several ways to follow a link, with or without a mouse. Users probably recognize what you mean, but you are still conveying the message that you think in a device-dependent way.

There’s usually a fairly simple way to do things better. Instead of the text “For information on pneumonia, click here”, you could simply write “pneumonia information”.

Accessibility isn’t something that can be left to developers to worry about.

Evaluating accessibility the TechDis way

Yesterday I received a word document via email from a colleague which served as my introduction to the http://www.techdis.ac.uk project. This is a JISC funded resource that seeks to a resource to assist in implementing accessibility and usability in a range of organisations. Read their site for a more detailed explanation.

I’ve had a quick look at the document and it piqued my curiousity. Over the past three or so years we’ve aimed to integrate accessibility and usability into all the new work that we create, but we’ve been remiss in formalising what we’ve done and documenting the methods we’ve used in aiming to make our sites usable and accessible.

Over that period we’ve had many discussions within the team about the pros and cons of particular methods but we’ve no record of our thought processes. I reasoned that an evaluation exercise would shine a light on our decision making and help us to do things better. An immediate attraction of the word document is its brevity.

Once one has selected the URL’s you wish to evaluate it’s away you go with the technical stuff. I’ve decided to look at Glamlife , one of our sites that should be pretty accessible, so that I don’t have too daunting a list of things to fix, and the evaluate the evaluation! The URLs I’ve chosen to test are

The home page, a section home page and a content page.

Technical HTML Conformance

“Each HTML page should be put through at least one HTML validator and each CSS should be validated using a CSS validation service.”

I used The W3C Mark-up Validation Service

The one remaining error on the home page is an element that we use in our rollover javascript. An explanation of how this works can be found on http://jehiah.cz/archive/simple-swap I currently don’t know how to change this so that it validates, but it shouldn’t cause the page to choke on any accessibility tests so we can leave it in. It’s only on this page so my efforts are better employed elsewhere.

The section homepages are a different layout and based on a different template, and all validate as XHTML 1.0 strict. Being based on templates the overwhelming majority of pages validate, unless there are things entered in the content that break the validation. This is an unavoidable hazard of a CMS. However, it’s worth remembering that valid does not equal accessible. Validation is just one of the tools available to us that assists in assertaining that our code is of a certain standard.

CSS Validation

A quick run through of the CSS we use for glamlife came up a with a few errors, which were easily fixed. I think the CSS for the site could do with some tidying up, to make development easier

Screen Size/Resolution

The TechDis site recommend http://www.anybrowser.com/ScreenSizeTest.html as a resource to test ‘common’ browser resolutions, though they seem pretty tiny to me. The copyright info on the page says 1995-2001, so presumably this is when the info was relevant. Instead of that I’ve chosen to check our general site stats, and as at Feb 2007 we’ve around 10% of users using 800×600 resoultions. We’ve been pretty conservative with our design to accommodate this size.

Enlarging the font size

The font size scales up well in Safari and goes up and down through the text size options on IE6 on XP. (the smallest size is almost illegible), which I think is a common problem.

Is the site usable without images?

Yes

Does the site work without JavaScript?

Yes

Can you use the site without using the mouse?

I can tab through the site, but to thoroughly test this you would need to have input from someone for whom this method of navigating a site is important. How one lets the user know about the keyboard shortcuts that we use is an important question that needs more work. We have however, chosen our access keys with regard to the UK government’s advice

Navigation without a mouse (or other pointing device) is something that we need to get out and learn more about. And the Tab order of the page is something that we can defininitely develop some University standards on. The access keys for Glamlife can be found on the Accessibility Statement page.

Automatic Checkers

The guidance from TechDis recommends some automatic checkers

http://www.cynthiasays.com/ Used this to check, using the WCAG priority 1,2 and 3 options. One error we had was on link text. The checkpoint is 13.1 Clearly identify the target of each link. The fix for this will be a small change to the content.

Webxact

We used webxact throughout the development phase of Glamlife and so it does not flag up many errors and/or warnings. The one error that comes up is something that we have looked into and may look into again. It certainly not a showstopper.

Accessibility Heuristic Evaluation

This sounded quite daunting to me until I realised that it’s a method to include some judgement based criteria for any site that you care to evaluate. Essentially one answers the following questions and assigns scores for how fully you feel the site satisfies the questions. There is a fuller explanation on the TechDis site.

  • Does the website have a clear, intuitive and logical navigation structure?
  • Does the website have a clean, consistent and clear visual design?
  • Does the site provide appropriate alternative descriptions for all visual elements?
  • Are all the website interactions, forms, navigation scripts etc accessible and usable?
  • Does the website use clear and simple language, appropriate for its audience?

We can answer yes to all these questions, gaining 3-4 points for each answer. Which tells us that we are doing ok. They are very useful for providing a mechanism to evaluate non-technical issues, matters of personal preference or other qualitative issues.

Usability Heuristic Evaluation

Similarly we score well on the usability Heuristics too. We’ve kept the site pretty free of inappropriate Frames, Java, Flash and animation, and the content is clear and well written.

Assistive Technology Testing

We have tested the site with the screen reader that is installed as standard in the IT labs here at Glamorgan, however, This is of limited value because we are not regular users of the software, and consequently this skews the tests. Useful feedback would come from a regular screen reader user.

Just prior to launch I posted a request for users opinions on the accessify forums, and was rewarded with some useful feedback.Specifically, a user explained what was being read out when he viewed the site suggested some changes to our access keys and a few other things about what was actually being read by his screen reader. Which we then implemented. The whole area of assitive technology testing is an area that the University needs to get to grips with. We have done what we can.

Browser Compatibility Testing

Have tested on IE6, Firefox,Safari which are the most popular on our site with approx 98% of users using them. We also feel that the web standards based approach that we’ve taken is likely to be helpful to users with browsers that we have not directly tested.

Conclusion

The evaluation exercise has been good to go through, but it does take some time. If one was doing it for sites with bigger issues about accessibility then I can imagine it would be an arduous task, but a completely necessary one. Accessibility and Usability was central to Glamlife from the start and it still threw up some issues, and continues to do so. They are not features that once provided can be ticked, it is a continual process of evaluation and development.

If you’ve found this article interesting, please add some comments. As a team we are always keen to get feedback on what we do.

A cite for sore eyes

Researchers are required and need to refer to papers, articles etc as evidence of their research activity, as a consequence the research sites will soon have lots of publication information available, and a quick glance at the sites shows that there is work to be done on semantically making sense of the information.

The LRC have produced
http://www.glam.ac.uk/lrc/about/help/guides/gencitations.php

This example of a journal publication from http://genomics.research.glam.ac.uk

  • Burke, S and Kirk, KM1
    Genetics education in the nursing professions: a literature review
    Journal of Advanced Nursing, 2006 54(2): 228–237,
    ISSN 0309–2402.

This comprises of the Author name/s, the Article title ( usually quite long), the Journal name, a date when the article was published, the volume of the journal ( in this case 54), the number. The pages the article can be found on, and an ISSN number (explanation here http://www.bl.uk/services/bibliographic/issn.html)

This is the textile necessary

*(pub) Burke, S and Kirk, KM"^1^":#1
??Genetics education in the nursing professions: a literature review??
_Journal of Advanced Nursing_, 2006 *54*(2): 228-237,
ISSN 0309-2402.

One of the problems with this is that only the title is contained within the cite tags. It would be better if all the text is contained within the cite. For such sematically rich information I think that HTML is the best way to mark it up.

  • Burke, S and Kirk, KM 1
    Genetics education in the nursing professions: a literature review
    Journal of Advanced Nursing, 2006 54(2): 228–237,
    ISSN 0309–2402.

I think this is a better more useful way to mark up a publication. The whole entry is now cited rather than just the title, there also more classes that we can hang CSS styles on, and the classes can also serve to explain a little to authors of the code what the information means.

It can serve as a useful starting point for when we start to pull publication info out of a database.

Other things to think about are the possible use of a citation microformat, and we also need to get further information about how we can display the data to correspond to the variety of citing style out there.