Inspect32 is a tool from Microsoft that enables a developer to verify that information is being correctly exposed through MSAA (Microsoft Active Accessibility). MSAA is an information source for an assistive technology. As a developer or tester, by verifying that the “Name” property is being passed through, you will be able to ensure that screen readers can properly read the labels for your content to a visually impaired person.

Download Inspect32 from here.

Watch Video Tutorial Full Screen

Testing Style Sheets is the easy part, figuring how to do it can take a little more time.  I’ll do my best with this blog to keep things simple so you can help make your web based product accessible and show you how you can test it.  Cascading Style Sheets or CSS is a very common technique used in web page development.  With a single CSS, fonts, colors, layout, etc… can be defined saving time and energy in web page creation.  The purpose of our blog is to focus on accessibility issues for users ranging from mom and dad at home to the developers themselves.  Testing Style Sheets is probably less relevant to mom and dad and more focused on a web developer and the test staff to verify that by using CSS the web page is still accessible to those with disabilities. 

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.