The guidance on this site seemed very detailed and in depth so I thought I would review it in case I could pick up something new.

The Problem

As I read through the site I came across a statement that said the style for Header 1 (that is heading level 1) should only be used once in a document and that it should be used as a title. I am not sure why this advice was being given because Word provides a style for the title of a document. The style is called, oddly enough, ‘Title’. In fact, using the ‘Header 1′ style for a title is going to cause problems with your table of contents, if you choose to use a TOC.

The site went on to describe how to remove the Header 1 style from the TOC outline. I thought to myself, “Hmmm. Why would they do that? Maybe they don’t like the way the Title style is formatted. If that is the case why don’t they just modify the style to look the way they want?”

As I continued to read it was mentioned that there is a bug with the TOC in Word 2003 and that a after the TOC is created in a document the user should cut and paste the TOC into Notepad. Then after that they should copy the TOC from Notepad and paste it back into the Word document. What?!

All the advice this site had given was pretty accurate so far. This business about using Heading 1 as a title was a bit odd but now this TOC stuff was just plain ridiculous. If I follow the advice on the TOC all I have done is negated the benefit of having a TOC in the document! For example the bookmark links were automatically generated are now gone. Any formatting that the TOC had is now gone. I also no longer have the ability to update the TOC should I make changes to my document. If I do make changes to the document I have to recreate the TOC, paste it into Notepad and then back into Word and manually reformat the entire TOC. Why would they give such crazy advice?

The “Ah-Ha!” Moment

Now at this moment I would usually just close my browser and say, “What is wrong with the people who created that site?” But something was nagging at me to look further into what they really were trying to accomplish. The site mentioned that this TOC workaround needed to be done because there was a bug in Word 2003 and the way it handled the table of contents. It also said that this issue had been fixed in Word 2007. The site didn’t go into detail about this mysterious issue that caused them give such nonsensical advice.

So I decided to break out my install of Office 2003 and poke around a little to see what I could figure out. As I tried different things I quickly discovered an issue with the TOC. Some of the heading levels were not showing up in the TOC! I tried the same steps in Office 2007 and found that this behavior was not happening in that version. Could this be the reason for the strange advice being given?

I am not sure if this is the reason, but it does tie the header and TOC advice together or at least places them both at the scene of the crime. I am going to assume this must be the apparent ‘bug’ that was referenced.

The Fix!

As I contemplated why the TOC in Word 2003 was not including all the headers in the document I discovered the reason by showing the formatting marks in the document. This is done using the Show/Hide command button while in the Normal (Print Layout in Word 2007), Web Layout or Draft Layout views.

To turn this feature on and off you select the button with the paragraph mark on it  or use the keyboard shortcut which is Alt+Shift+*. When it is on your document will include the various formatting marks demonstrated in this screen shot:

What I noticed is if a page break was used and there was no carriage return just before the break then the heading that followed on the next page would not show up in the TOC.

How could this happen? An example would be that you are typing in Print Layout view and you have inserted a page break. You notice that there appears to be an extra line below the last paragraph on the page. It looks this way because the cursor is sitting there flashing at you (this is due to the carriage return).

So you use the backspace key to remove that apparent extra empty line. When you do this you have effectively removed the carriage return. Now the paragraph and page break no longer have a carriage return to separate the two.

Here is an image of how the document would look with the the carriage return properly located between the end of the paragraph and the page break:

When the carriage return is removed this creates the situation as demonstrated in the image below:

That carriage return is essential if you want the header style at the top of the next page to be included in the TOC.

If you are a user of Word 2003 go give it a try and see for yourself! If you find that the header does not get added back to the TOC after you re-add the carriage return, then select the header text and reapply the style.

Summary

Now I am not sure if this is in fact the issue that was being discussed on the site I mentioned earlier. If it is or is not the fact is the advice that was given on that site is just plain bad advice.

By using the proper styles and other features in Word such, as the Table of Contents, correctly your document will be better structured as an accessible document. Then if you export your document to a PDF format that structure will be exported also which again provides better accessibility.

Now I don’t want to knock the effort that was put into creating the content on the site mentioned above because the majority of it was correct. I want to encourage more effort to share this type of knowledge. This way we can help to ensure that content is accessible to all users.

That being said, I also want to encourage that any advice that is given be as accurate as possible. If you run into issues like that demonstrated in this blog post please don’t just make things up. Take the time to do your own research and post comments and questions on blogs like this one. You may find someone who can provide you the solution.

Most importantly do not assume that everything you read online as correct. Do your due dillegence! As mentioned in the title of the post, when it comes to free accessibility advice…caveat emptor!

If you disagree with my comments, have run into similar situations or have any questions on accessibility issue s please post your comments and questions here.

I first became aware of the new version of this editor from the following news article: FCKEditor drops the F. This article mentioned that the editor was now ‘fully’ accessible to screen readers and keyboard only users. Even the main page for the CKeditor website (http://ckeditor.com/) makes the claim that it has full accessibility support.

This editor is open source and versatile when it comes to implementation so it is has a large install base. You may have used this editor yourself without even knowing it. With the growing attention to accessibility and the legal requirements around this topic an updated ‘accessible’ version of this editor is very timely.

I have done some testing in the past with the FCKEditor in regards to accessibility and was curious if this new version was really accessible. So I took a ‘quick’ peek to see for myself. My focus for this quick test was not if the editor created accessible content, but on if the editor itself was accessible.

Keyboard Only

I was pleasantly surprised to find that the CKEditor does in fact support the use of only a keyboard! Many of the past keyboard problems with the FCKEditor have been fix. I honestly did not expect the level of keyboard support that I found in the new version of this editor.

To say the least I was very pleased! The one drawback was finding the reference to the keyboard only commands. It wasn’t that hard to find but did take me a few minutes. What would be nice is to have a link or easily discoverable way to allow a user to get this information from within the editor itself.

You can find the reference for the most common supported keyboard commands and navigation shortcuts in the CKEditor Accessibility topics document.

Screen Reader

When it came to using a screen reader like JAWS with the CKEditor I was sure I would discover some major issues. Again, to my surprise JAWS and the CKEditor worked fairly well together. There is still a steep learning curve and at times JAWS got lost which required some screen refreshing and rediscovering of current focus to get my bearings. Compared to the way JAWS and the FCKEditor worked (or should I say did not work) together in the past this was a tremendous improvement.

To CKEditor’s credit most issues of using JAWS with this product are documented. This was in the CKEditor’s Accessibility document mentioned early or if you prefer jump directly to the JAWS section of that document here.

In case you are interested I used IE 7.0.6001.18000 and JAWS 10.0.1142 for my testing.

In Summary

There are still some areas that are problematic such as switching from WYSIWYG view to the Source view. When this switch occurs the focus jumps from the editor to the top of the page. This is not good for a screen reader user, screen magnifier user or a keyboard only user.

Also, I was not able to find a complete list of keyboard commands for ALL available tool bar options. It could be that those have been deprecated. The FCKEditor had a much larger list than that outlined in the current CKEditor Accessibility Document.

In all fairness I did not do an exhaustive search but I still feel a reference like that, if still applicable,   should be easily discoverable and even be referenced within the CKEditor Accessibility Document.

I should also mention that I did not do a complete test of the editor for accessibility but took a high level approach. Even so, that high level approach shows that the creators of CKEditor have put great effort in making this an accessible product.

This is very commendable because all too often the minimal effort is done so a product can be called accessible. I am not saying that the CKEditor does not have accessibility issues but compared to the previous versions of the FCKEditor the difference is night and day! This was a *real* effort to create an accessible product and so I offer a hearty ‘WOOT!’ to the CKEditor team!

If you have had a similar or different experience with the new CKEditor please post your comment here.

What often gets overlooked is the usability of the site. No matter how ‘compliant’ your site is it can still be unusable or at least not as easy to use as you may think. How so?

Let me give you an example. I was recently in a meeting with a client who is a large scale e-retailer. Much discussion was going on about how the trailer videos for some of their products are not captioned and how this may expose them to litigation by groups such as the National Federation of the Blind (NFB).

This company is fully committed to making their site accessible and if they could not get captioned videos they were going to pull the videos from the site! This is very commendable and it is also very refreshing to see a company with that kind of commitment to accessibility. Unfortunately they had not given much thought to the usability of the site…at least from the accessible view.

After the discussion on video captioning was done I brought up the topic of usability. I was informed that their testing includes the use of JAWS to verify the pages. This again is very commendable. I don’t encounter too many companies that bother to test their sites with a screen reader! Unfortunately the testers making use of this technology are not really attuned on what to check for. They listen to make sure the screen reader is reading out the text and controls but never really ‘hear’ what is being conveyed.

To demonstrate I used this e-retailer’s main landing page and immediately found two issues that a focused usability test pass would have disclosed.

First, products were being displayed with two prices. The retail price formatted with strike through text and then the sales price in bold colored text like this:

$159.99
$99.99

When the screen reader rendered this part of the page the two prices were read equally. There was no indication, other than the visual formatting, to let the user know what the real price of the item was.

Second, an image was used to promote the pre-order of an upcoming release of a product. This simply was comprised of an image which visually provided all the information a user would need to know. Unfortunately the ALT text for this graphic link only said, “Preorder order it now.” This leaves the screen reader user wondering, “Preorder what now?!”

Granted these seem like issues that could easily be figured out by your typical screen reader user but why make the user figure things out? A good user experience means that the site is usable without the second guessing and extra effort needed to investigate what the content really means. This leads to a great user experience, a happy customer and ultimately repeat sales if you are an e-retailer.

Not only does usability lead to a great user experience it also means that you are essentially limiting your exposure to litigation. If an Assistive Technology user can easily access your site, find what they need and make a purchase or retrieve the information they are looking for then why would an organization like the NFB bother with targeting that site for a lawsuit?

I am not saying that ensuring your site is complaint with the standards is not important but it does underscore that usability should be just as important. It helps in making your users happy and in avoiding situations where litigation could become an issue.

If you are expending resources on being compliant do yourself a favor and include usability as part of your accessibility efforts. Should you need help in this area or require an outside consultant to provide this service feel free to contact me and I can point you in the right direction.

Download Inspect32 from here.

Watch Video Tutorial Full Screen.

It has been my experience that the subject of bug reporting is not covered properly in the schools and text books that deal with software testing. Even many of the biggest software development companies overlook the value of complete and effective bug reporting.

I gave a lecture on this subject at the California State University Northridge (CSUN) Technology & Persons with Disabilities Conference back in March of 2008. Since then I have seen signs that this trend is starting to change. The feature article in the September 2008 issue of “Better Software” magazine would be one such sign.

Now I am not sure if the person who wrote this article was at my lecture or not, but I can say that I am glad to see that bug reporting is starting to get some attention! The article mentioned above does a great job of going into detail on this. What I want to offer here is my approach to writing complete and effective bug/defect reports as it is more simplified and therefore easier to implement. I am not saying my way is best by any means. All I can say is that I have used it in the past and the method has worked everywhere I have used it.

While writing complete and effective bug/defect reports are important for all aspects of software development, it is even more important when it comes to issues that involved accessibility. Why? Because most people (Developers, Program Managers, Testers/SQA) are new to accessibility and often times don’t see the need to focus much attention on that subject. So the way in which you write your reports is going to have a bigger impact on changing this viewpoint.

What are the potential benefits of writing complete and effective bug reports?

• Time Savings for You
• Quicker Bug Fix Turnaround
• Tester Credibility

How is there a time savings for you? The more information you can provide the less likely you will be interrupted in the future with questions from the Program Managers and Developers looking further clarification.

You will also save time when the fix for that issue comes back to be verified. In this case you will spend less time trying to “remember” what the issue was and can jump right into testing the fix.

Don’t underestimate just how much time this can and will save you in the future!

How do you get a quicker turnaround on fixes? Because you are writing complete and effective reports these bugs will be triaged quicker and given to the development teams sooner.

You will build your credibility as a tester because as you consistently write complete and effective bug reports those who read those reports will start to notice the difference between your bugs and those of your peers.

As your credibility grows you may also experience less push back on your bugs because you will have gained the reputation of providing informative and accurate reports. If you are in an organization that considers the amount and quality of your bugs when the time for salary increase comes around, then you certainly don’t want to miss a chance to set yourself apart from the pack!

So there are benefits, I have personally experience those. You are likely wondering what to include in a bug report. Well I will tell you…

What to Include in a Bug Report

The format I follow is:

• Title
• Description
• Customer Impact
• Work Around
• Details
• Repro Steps
• Results
• Expected

Let’s take a more detailed look at each one of those bullet points.

Title
The title of your bug should be short but meaningful. What you want to accomplish here is to define the bug so that anyone looking at the title can understand the basic issue. This is important because when you go looking for this bug in your bug reporting system, you want to be able to distinguish it without having to open every bug to make sure you have the correct one.

For example an accessibility bug title could look like this:
“Project A Main page is missing skip navigation link”

Which is much more meaningful than this:
“Skip navigation link missing”

Another trick that is useful is to preface your titles with an identifier. This is not always necessary, but if you are tracking a lot of bugs and not all are dealing with accessibility then this can save you time by giving you a means to quickly sort your bugs by title or at least identify that the bug is an accessibility issue. Taking our example above you could create a title like:

“SEC508: Project A Main page is missing skip navigation link”
or
“ACC: Project A Main page is missing skip navigation link”

Choose any variation you like as long as it makes sense to you and those who will be reviewing your bugs.

Description
The description is a brief non-technical overview of the issue. The goal here is to convey the high level meaning of the bug so that those who are not the most technical people (i.e. managers) can understand what the issue is without having to come to you for clarification. Again, our goal is to save time by avoiding these interruptions

If done right, a manager will be able to know what the issue is based on the title description fields. They need not look any further.

Customer Impact
Many times bugs are deferred or closed as “won’t fix” because there doesn’t seem to be any clear customer impact. As a tester it is your job to put yourself in the customer’s shoes. If you can provide a details on how this will impact the customer negatively then outline that in the report.

What this does is show that you have given thought to the issue and what it will mean to the customer. This is something a lot of testers do not do! Talk about setting yourself apart from the rest of the testers!

Keep in mind that if there is no real negative impact on the customer we don’t want to make one up. You are building your credibility as a tester; don’t screw that up by stacking the deck with incorrect statements.

Work-Around
A bug may not be fixed if there is a valid work-around that is easily discoverable by a user. If such a work-around exists, call it out in the bug. Again, we want to state the facts even if it means our bugs may not be fixed. This all goes back to building our credibility as a tester.

Details
The details section is our catch all. Most importantly, this is where the technical details of the bug go. So what type of things may that be?

Call out what version of the OS and other software that may be involved in this bug. If you are using an Assistive Technology (AT) such as JAWS be sure to specify that version as well.

In addition to calling out the versions, if there is a tool being used, be sure to reference where a person can get a copy of that test tool. Also include the steps needed to execute the tool to run the test that discovered the bug. What this does is allow someone else to reproduce the bug and provides you a great summary of the steps you took initially. Again saving you time in the future when you need to verify the fix for the bug.

When you do provide instructions on how to use a certain testing tool or an AT that you used for testing, give the developer some insight on how they can also use the tool to verify their code. This means that the proactive developer will catch initial problems before they ever get to you. Again, saving you time!

If there is a certain accessibility requirement that has failed, you can also call that out in the details section. This saves time by identifying the requirement that has not been met. In the case of Section 508 requirements this means those looking at your bug don’t have to spend time trying to figure out which requirements have not been met. This can potentially save your time and certainly save the triage team’s time. Did I mention tester credibility?

For those testers who are a bit code savvy and take the time to dig in to the code to see what the issue might be, include the code snippet in the details section. Any developer worth his salt will welcome the insight. Even if you are wrong in your debugging efforts it still gives the developer a good place to start and I haven’t met many who frown on getting a little help.

You have carte blanch when it comes to the detail section. Just remember to keep the information there relevant to the bug and professional so that the reader is not wasting time. The idea is to provide all the necessary information that will allow the triage team and developer to address the issue without having to come back to your for clarification.

The article mentioned above has some good insight and advice on the amount of content to include. Check it out!

Repro Steps
The repro steps section is where you spell out, step by step, what you need to do to reproduce the bug. Don’t assume that the person attempting to do this will know how to use the test tool or how to navigate to a particular dialog etc. Take the time to include everything here,if only for the sake of documenting it for your own needs. Too many times in the past I have had a bug returned to me for verification 6 months, 9 months or a year after I wrote the bug. Having these steps clearly documented saved a lot of time!

Results
The results section is where you outline what happened. It is pretty simple and straight forward, no?

Expected
Under the expected results you stated what should have happened. Why is this important? Because sometimes what you expect to happen and what the developer expected to happen can be two different things. In situations like this you may find a design change happened because of your bug! A feather in your cap!

The other benefit of knowing what to expect is that you give the pass criteria for anyone else who may need to create the fix or verify the fix for this issue. Again, tester credibility comes to mind.

In summary, this post is in no way meant to be a complete or comprehensive list. Many pages could be written on this subject and each person may have a different view as to what should and should not be included. I can tell you that this method has worked for me. I offer it to you as a way to determine what will work best for you and to hopefully get you thinking about the quality of the bug/defect reports you create. With that in mind I have included a sample report below that follows the guidelines outlined above and a Word doc that you can download and use a template as you see fit.

All I ask is that if you find success with this method of bug reporting, that you drop me a line and let me know.

Sample Bug Report

Bug Reporting Template

Fortune 500 companies and the kids at home that all create web pages do it differently, but there is no authority to make them do it right.  The closest we can get are regulations such as the federal governments Section 508 Subpart B, more specifically 1194.22 that regulate web-based intranet and internet information and applications, in use by the federal government.    

1194.22(d) is the Section 508 subpart that deals with Style Sheets and to summarize, it basically states that pages must be readable without requiring an associated style sheet.  To make it simpler it means that the same content and functionality must be present with style sheet support disabled in the web browser. 

For a web developer or tester what can be done to verify this?  This is somewhat dependent on the browser and version being used.  Internet Explorer and Firefox are probably the most common web browsers so I’ll address how to disable CSS in them.   

Disable CSS in Firefox

1. Select “View”
2. Choose “Page Style”
3. Select “No Style” 

Disable CSS in IE (IE 3.x and older)

1. Select “Edit”
2. Select “Preferences”
3. Choose “Web Browser”
4. Choose “Web Content”
5. Deselect “Show Style Sheets”
6. Select “OK” 

Disable CSS in IE (IE 5.x and newer)  ***This will be most cases***A quick snippet on this is that IE removed the ability to disable CSS in these versions.  The only option to disable this would be to do a simple registry edit that can be seen at http://support.microsoft.com/kb/183717. 

Having now disabled CSS in your browser you can see by opening a web page that it may appear very differently.  However for persons that cannot see the screen, its appearance is irrelevant and the page needs to function the same.  This also allows the use of screen readers such as JAWS to essentially read the page to the user properly, www.google.com is a very good and simple example of this. 

Sample Test Case:

1. Disable style sheet support in your browser.
2. Inspect web page visually and with an AT (Assistive Technology such as a screen reader) to be sure all relevant content is still available and functional.

Pass/Fail Criteria for Sample Test Case:

Pass:

1. All information on the webpage is readable both visually and with AT, and no content or functionality is lost when the style sheet support is unavailable. 

Fail:

1. Any content on the webpage is missing or unreadable via AT when the style sheet is turned off.

 The best and quickest way to test this page now is to try using a screen reader and/or keyboard only functionality to verify that all links, buttons, text fields, etc. still function properly as described above in the Sample Test Case section.

Accessibility is something that really should be built in to every web page and application being created.  It is simple to do and markets a company to a larger audience.  As a computer user, web surfer, IT professional, etc… I believe its one thing to tell people they should be doing something, it’s another to show them how to do it.

This entry was posted on November 13, 2007 at 4:10 pm and is filed under Testing. Tagged: 508, accessibility, CSS, disable, Firefox, IE, jaws, screen reader, style sheets, test. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Some dialog windows do not interact with JAWS in the expected way. When this happens there is text within the dialog that does not get read. Typically you will hear JAWS read only the buttons on the dialog and if a link exists you will hear that read as well when you arrow through the dialog. But the descriptive text that explains what these controls are for does not get read by JAWS.

When you encounter one of these misbehaving dialogs you may try using a command such as ‘Insert + B’ to have JAWS read the current window. Unfortunately because this dialog is not behaving as a normal window JAWS will start reading the text and controls that are found on the application behind the dialog. Eventually JAWS will read the text within the dialog but by this time things have gotten really confusing and you are likely not going to realize what JAWS is reading to you.

In such cases you can route the JAWS Cursor to the PC Cursor to reveal the text on the misbehaving dialog window.

What are the JAWS Cursor and the PC Cursor? Navigating through Windows with JAWS is accomplished with cursors. These cursors determine the focus of JAWS speech and are often directly linked with Windows cursors.

The PC Cursor is linked to the keyboard functions of Windows and applications. This is the cursor that is used when typing information, moving through options in dialog boxes, and selecting options or icons. As you type information, the PC Cursor follows along with each key you press. If you are making a selection in a menu or dialog box, the PC Cursor highlights the currently selected object. The PC Cursor is activated by default when JAWS starts.

The JAWS Cursor is linked to mouse pointer functions in Windows and other applications. It is used to read information the PC Cursor cannot read, such as toolbar information. The mouse or mouse pointer follows along with the JAWS Cursor when it is moved, and you therefore have access to information in an application window that is beyond the scope of the PC Cursor.

There are other cursors in JAWS such as the Virtual PC Cursor that is used when in an HTML environment. We are not going to talk about those cursors here. But if you want to know more about the available cursors in JAWS and how to use them open the JAWS help and in the search tab search for “about cursors”. This will get you started in learning all you want to know about the available cursors in JAWS.

Wait a minute! What about that misbehaving dialog and using the JAWS Cursor to read its contents? I am glad you asked. This is how it is done:

• With the dialog window displayed route the JAWS Cursor to the PC by pressing Insert + ‘-‘ on the keypad ( CapsLock + ‘[‘ if using a laptop layout). This guarantees that the JAWS Cursor lands on top of your PC Cursor which is inside the dialog window.
• Press the ‘Page Up’ key to set focus to the top of the dialog window.
• Arrow Key down through the dialog to read each line of text and controls
• Activate the PC Cursor again to continue normal operation

To activate the PC cursor (or stop the JAWS Cursor from following the PC Cursor):

• Press Insert + ‘+’ on the keypad (CapsLock + ‘;’ if using a laptop layout)

That’s it! I hope this will help solve any problems you encounter with misbehaving dialog windows that come your way.

Fortune 500 companies and the kids at home that all create web pages do it differently, but there is no authority to make them do it right.  The closest we can get are regulations such as the federal governments Section 508 Subpart B, more specifically 1194.22 that regulate web-based intranet and internet information and applications, in use by the federal government.    

1194.22(d) is the Section 508 subpart that deals with Style Sheets and to summarize, it basically states that pages must be readable without requiring an associated style sheet.  To make it simpler it means that the same content and functionality must be present with style sheet support disabled in the web browser. 

For a web developer or tester what can be done to verify this?  This is somewhat dependent on the browser and version being used.  Internet Explorer and Firefox are probably the most common web browsers so I’ll address how to disable CSS in them.   

Disable CSS in Firefox

1. Select “View”
2. Choose “Page Style”
3. Select “No Style” 

Disable CSS in IE (IE 3.x and older)

1. Select “Edit”
2. Select “Preferences”
3. Choose “Web Browser”
4. Choose “Web Content”
5. Deselect “Show Style Sheets”
6. Select “OK” 

Disable CSS in IE (IE 5.x and newer)  ***This will be most cases***A quick snippet on this is that IE removed the ability to disable CSS in these versions.  The only option to disable this would be to do a simple registry edit that can be seen at http://support.microsoft.com/kb/183717. 

Having now disabled CSS in your browser you can see by opening a web page that it may appear very differently.  However for persons that cannot see the screen, its appearance is irrelevant and the page needs to function the same.  This also allows the use of screen readers such as JAWS to essentially read the page to the user properly, www.google.com is a very good and simple example of this. 

Sample Test Case:

1. Disable style sheet support in your browser.
2. Inspect web page visually and with an AT (Assistive Technology such as a screen reader) to be sure all relevant content is still available and functional.

Pass/Fail Criteria for Sample Test Case:

Pass:

1. All information on the webpage is readable both visually and with AT, and no content or functionality is lost when the style sheet support is unavailable. 

Fail:

1. Any content on the webpage is missing or unreadable via AT when the style sheet is turned off.

 The best and quickest way to test this page now is to try using a screen reader and/or keyboard only functionality to verify that all links, buttons, text fields, etc. still function properly as described above in the Sample Test Case section.

Accessibility is something that really should be built in to every web page and application being created.  It is simple to do and markets a company to a larger audience.  As a computer user, web surfer, IT professional, etc… I believe its one thing to tell people they should be doing something, it’s another to show them how to do it.

It’s easy to create a document and throw in a picture or graphic but by doing so it can quickly make that document non-compliant (at least to the section 508 accessibility standards.)  It can also keep screen reader programs such as JAWS from identifying and reading these graphics.  So in a Word document just how would we make it accessible?

Alternative text is really the key as most screen readers can easily read through the normal text of the document but usually hiccup when coming across a picture, chart or some other graphic.  By simply adding alternate text to these graphics you can help ensure that you’re document is readable (in a sense) by everyone.

Word reacts very similar to Outlook so this is a two for one as the below steps should work for the corresponding Outlook version as well.

Office 2003 (Word):

With an image embedded in your document…

1.       Right click image

2.       Select “Format Picture…”  (there is also a “Format Picture…” available in picture toolbar

3.       Select “Web” tab

4.       Type Alternative Text in the field that matches the content of the graphic

5.       Select “OK” button

Office 2007 (Word)

With an image embedded in your document…

1.       Right click on image

2.       Select “Size”

3.       Select “Alt Text” tab

4.       Type Alternative Text in the field that matches the content of the graphic

5.       Select “Close” button

Keep in mind there are multiple scenarios depending on your expertise and usage of Word.  The rule of thumb is that if you are conveying a message with something other than text, it should also have a textual representation.  Links tend to be self explanatory but what about a button that launches a link?  The buttons alternative text should be something like “Select here to go to http://theaccesspond.com/”

There are additional benefits to the practice of adding alternative text in that when saved as an .htm or .html file the alt text will appear for all users when the graphic is scrolled over with the mouse and be read by assistive technologies like screen readers.  There are some differences between the two versions of Word but the end result is the same…you have now made your embedded graphics in a Word document accessible.

Office 2003 (PowerPoint)

1.        Right click on image

2.       Select “Format”

3.       Select the “Web” tab

4.       Type Alternative Text in the field that matches the content of the graphic

5.       Select the “OK” button

Office 2007 (PowerPoint)

1.        Right click on image

2.       Select “Size and Position”

3.       Select “Alt Text” tab

4.       Type text into “Alternative Text” field.  (Text should generally describe the graphic it is referring to).

5.       Select “Close” button

Making a PowerPoint presentation fully accessible is its own monster and there are third party tools that can assist you but they come with a price tag.  Really there are only a couple of ways to really make a PowerPoint presentation fully accessible.  The first option is to simply create an .html version of your presentation and this is what some third party tools will assist with.  The other which to me is more feasible is to utilize the Outline function of PowerPoint.  Utilizing the outline and using metadata along with alternate text gives you the best opportunity to be accessibility compliant.

While the thought of making your items such as Word documents or PowerPoint presentations accessible may sound a little scary, I hope I’ve been able to show you a few very simple ways you can help make these items accessible for anyone that may be using or viewing them.

When you encounter one of these misbehaving dialogs you may try using a command such as ‘Insert + B’ to have JAWS read the current window. Unfortunately because this dialog is not behaving as a normal window JAWS will start reading the text and controls that are found on the application behind the dialog. Eventually JAWS will read the text within the dialog but by this time things have gotten really confusing and you are likely not going to realize what JAWS is reading to you.

In such cases you can route the JAWS Cursor to the PC Cursor to reveal the text on the misbehaving dialog window.

What are the JAWS Cursor and the PC Cursor? Navigating through Windows with JAWS is accomplished with cursors. These cursors determine the focus of JAWS speech and are often directly linked with Windows cursors.

The PC Cursor is linked to the keyboard functions of Windows and applications. This is the cursor that is used when typing information, moving through options in dialog boxes, and selecting options or icons. As you type information, the PC Cursor follows along with each key you press. If you are making a selection in a menu or dialog box, the PC Cursor highlights the currently selected object. The PC Cursor is activated by default when JAWS starts.

The JAWS Cursor is linked to mouse pointer functions in Windows and other applications. It is used to read information the PC Cursor cannot read, such as toolbar information. The mouse or mouse pointer follows along with the JAWS Cursor when it is moved, and you therefore have access to information in an application window that is beyond the scope of the PC Cursor.

There are other cursors in JAWS such as the Virtual PC Cursor that is used when in an HTML environment. We are not going to talk about those cursors here. But if you want to know more about the available cursors in JAWS and how to use them open the JAWS help and in the search tab search for “about cursors”. This will get you started in learning all you want to know about the available cursors in JAWS.

Wait a minute! What about that misbehaving dialog and using the JAWS Cursor to read its contents? I am glad you asked. This is how it is done:

• With the dialog window displayed route the JAWS Cursor to the PC by pressing Insert + ‘-‘ on the keypad ( CapsLock + ‘[‘ if using a laptop layout). This guarantees that the JAWS Cursor lands on top of your PC Cursor which is inside the dialog window.
• Press the ‘Page Up’ key to set focus to the top of the dialog window.
• Arrow Key down through the dialog to read each line of text and controls
• Activate the PC Cursor again to continue normal operation

To activate the PC cursor (or stop the JAWS Cursor from following the PC Cursor):

• Press Insert + ‘+’ on the keypad (CapsLock + ‘;’ if using a laptop layout)

That’s it! I hope this will help solve any problems you encounter with misbehaving dialog windows that come your way.