Two articles on the history of PDFs:
I am pleased to report that my first talk on PDF Accessibility (PDF Accessibility I), held in Ottawa, was a great success.
The attendees had significant understanding of PDF or web accessibility or MS Word yet all of them went away knowing more than they did beforehand and feeling that the talk was well worth it.
I haven’t had much speaking experience lately but my couple of years of teaching really helped me. I wasn’t worried so much about presenting as I was about the content and whether the attendees would feel the content was beneficial. In the post-talk discussion, it was clear to me that they were very pleased with both although there were recommendations for improvement (even I stopped at one point to write a brief note to myself about an item I should incorporate next time).
One of the attendees felt that it would be excellent for his communications staff to attend this talk but it would be better if it was reworked as a more hands-on workshop filling a full day instead of just a half-day.
Looking forward to presenting it again in January, either as a talk or a workshop.
Next, is part II for more advanced techniques and information.
Recently, I have been playing around with Word 2003 and Acrobat Pro 8 in preparation for a course I am teaching on PDF Accessibility. I decided to experiment with bulleted and numbered lists to see what kind of results I would obtain using various options that are available for these formats and the results were quite disappointing, at least from my perspective.
With regard to web accessibility, the basic lesson that we try to teach is to use the appropriate structure or format for the content. Furthermore, if you don’t like the look of the default appearance of that structure, use CSS (Cascading Style Sheets) to change the appearance to something that you prefer. Underneath the visual appearance, the structure remains the same, it is just the look that changed.
My assumption (and perhaps that’s where I went wrong) was that the same principles apply to Word and PDFs: select the right structure for the content and change the style to meet your design needs. Although I haven’t found any issues with headings in Word and PDFs, lists are different beasts.
As far as I am concerned, the basic principles should be the same. The first is to use numbered lists where order or importance is significant and bulleted lists where order or importance is not significant. The second principle is that it shouldn’t matter what bullet character or bullet image or numbering style is used, the result should be the same: all bullet characters and images should be treated equally as bullets and numbering styles should all be considered to be a numerical sequence. Unfortunately, the second principle doesn’t seem to be supported by Word and PDFs.
Exactly where the problem is, I don’t know—it could be Word or Acrobat or both—nevertheless, the problem exists and, in my opinion, should be fixed as it could be a source of confusion for screen reader users (my limited experience has been only with JAWS).
The other aspect of this problem is that it is not the visual aspect of styled lists that is the problem, the problem is either or both of the PDF and JAWS. The basic premise of accessibility (web and PDF) is that everyone has equal access to the information but some of the list styles creates a hinderance for those who are using screen reader software. If the screen reader software is simply reading the content supplied to it from the PDF, then the PDF creation process needs to be fixed.
Lists Read by JAWS
When lists are encountered in a PDF by a JAWS user, JAWS states List of three items (or whatever the number of items happens to be). After reading out the content of the last list item, JAWS states List End.
As examples of lists, the two following lists were tested in JAWS.
Problems with Bulleted List Styles
The default bullet (●, solid circle) works out perfectly fine. When a list has been created in Word with this default style of bullet, the Word document has been converted to a PDF and read out by JAWS, each bullet item is preceded by an announcement of bullet before the list item text is read. Using the above list, JAWS read list of three items bullet cookie bullet milk bullet bread list end.
However, if you change the bullet character to the disc (○, open circle), each list item is preceded by an announcement of oh. Using a solid square as the bullet character causes JAWS to say filled square, using the diamond character causes JAWS to say black diamond suit and using the cloverleaf character might make you think that JAWS would say black club suit but in fact, nothing is said about the bullet character, only the list text content is read with no indication that it is part of a new list item.
Therefore, a bulleted list is not read as bullet followed by the list item text content but instead, the description of the bullet character is spoken and when the character is not known by JAWS, nothing is spoken. Although JAWS does announce the number of items in the list, it might be confusing for screen reader users to hear different bullet character descriptions in different documents or worse, not hearing a bullet character at all thereby leaving the screen reader user wondering where the divisions between the list items exist.
Problems with Numbered List Styles
The default style for numbered lists is to have each list item preceded by a number followed by a period such as 1. or 2. or 3.. When JAWS reads the list items in a numbered list that has been styled using the default numbering style, JAWS reads one, two three and so on. Using the example list above, JAWS reads list of five items one cookies two milk three bread four eggs five apples list end.
There also isn’t a problem when alphabetic characters are used such as a., b., c.. (It doesn’t matter to JAWS whether the alphabetic characters are upper- or lowercase, the characters are read the same way.) Again, using the same list, JAWS would read list of five items a cookies b milk c break d eggs e apples list end.
However, if Roman numerals are used, then JAWS reads the numbers strangely. Using the above list styled with Roman numerals (again, it doesn’t matter if they are in upper- or lowercase Roman numerals), JAWS reads list of five items i cookes two milk three break i v eggs v apples list end. In other words, i is read as the letter i not as the number one and iv and v are read as letters too but ii and iii are read as numerals 2 and 3. It is my opinion that Roman numerals should be read as the numbers they represent, not as the letters that are used to create the Roman numerals, and certainly not as a mixture of the two methods.
The situation gets more complex when you create custom numbering styles such as Item 1 or even as simple as (1). In the second example, it is read out as left parens one right parens and the first example is read as item one. While it does make sense that certain text surrounding the numeral be read if you highly modify the numbering style, the second example does seem to be a bit of overkill in terms of JAWS response. Perhaps the best advice to give, with regard to numbering styles and these customization options, is not to use them if you do not wish to confuse the screen reader users that read your PDFs.
Problems with Images as Bullets
Using an image as a bullet character should be no different than using another font character as a bullet character in that they should all be read out by JAWS as bullet. Unfortunately, the situation is worse than alternate bullet characters and I believe that the source of the problem is Word and/or Acrobat.
I tried replacing the bullet character twice with two different bullet images and two different results occured.
Using one of the supplied images (one that is installed with Word) as the bullet character, the resulting PDF had a problem with this from an accessibility perspective. After running the Accessibility Checker against the PDF, the checker flagged the images as images without alternative text. It is my opinion that the images should be considered bullets, not like other images that you might insert into a document (such as photographs or charts). If there is a need for alternative text, then Word should automatically assign bullet as the alternative text. Furthermore, I tried to manually edit the PDF and assign the images with alternative text but JAWS did not read the alternative text and the bullet images remained an accessibility checker issue.
Using an image I created (a small one that should have been suitable as a bullet image) as the bullet character, the PDF had 2 problems with this from both accessibility and usability perspectives. Like the bullet image problem above, the accessibility checker in Acrobat wanted alternative text for the image. A worse problem occurred as well which I can only attribute to the conversion of the Word document to the PDF. For some reason, the image was ignored as a bullet image and the PDF was marked up in such a way that the first letter of the list item text became the bullet character and the rest of the list item content missed that letter. Using the first list example above, cookies became c ookies, milk became m ilk, and bread became b read. Why this would happen with my created bullet image and not with a Word-supplied bullet image, I don’t know but I created the PDF a couple of times and the results were the same. I haven’t tried any other images since then.
Word users should be able to use different list style options and know that the PDFs they create from them will be as usable by screen-reader users as sighted readers. This means that, for bulleted lists, it shouldn’t matter what bullet character has been chosen, the screen reader software should simply announce bullet when a new list item has been encountered. Along the same lines, bullet images should receive the same treatment and not require alternative text (or as a compromise, bullet should be automatically be assigned as the alternative text).
Numbered bullet styles work fine when the Arabic numeral or letter (in either case, followed only by a period) are used as the numbering style. Word should be fixed so that Roman numerals be considered to be the same as Arabic numerals and read out as such. However, custom numbering should be read out as it has been formed and anyone who wishes to avoid any accessibility issues may wish to avoid using custom numbering styles.