Screen Readers lack emphasis
In a recent thread on the Web Standards Group mailing list, the question arose about whether Screen Readers support semantic HTML elements such as
em. The short answer for the two main screen readers JAWS and Window Eyes is no. Neither do they support
b for that matter. What is meant here by support is, do they using default settings provide an indication to the user by changing voice or some other method when text content is marked up using these elements, or do they have the option to provide an indication in their HTML specific settings.
A tweet by Dan Clark points out that JAWS has a document proofreading scheme called Proofreading (attributes), using this scheme italicized, stricken and bolded text is indicated by a change in voice, but there is no distinction between <em> or <i> and <strong> or <b>. He also mentions that JAWS schemes can be accessed via a dialog using the INS+ALT+S key combination.
Testing Support for strong and other elements
A simple test document was used containing example uses of the
del HTML 4 elements. Window Eyes 5.5 and JAWS 8.0 were used to read the test document in Internet Explorer 7.
Using the default settings, neither screen reader indicated the presence of any of the elements tested.
|strong||no indication||no indication|
|b||no indication||no indication|
|em||no indication||no indication|
|i||no indication||no indication|
|del||no indication||no indication|
|strike||no indication||no indication|
JAWS schemes and Window Eyes attribute settings
JAWS and Window Eyes have control panels that allow users to modify how various aspects of web pages are announced. For JAWS it is the HTML Options dialog which can be reached via ‘Utilities > Configuration Manager > Set Options’ . It provides no settings for the
em elements or any of the elements tested. Window Eyes has the ‘browse mode’ dialog accessed from the ‘Verbosity Options’ menu, again no settings for the
em elements or any of the elements tested.
JAWS has a general text reading feature called ‘Schemes’, that allows users to change what and how information about interface elements and text formatting is conveyed in all applications . It can be found in the ‘Speech and Sounds manager’ dialog. Different schemes can be chosen that provide extra information to the user that is not provided in the ‘Classic’ (default) scheme.
Unfortunately none of the pre-configured choices provide for providing indications of bolded or italicised text alone, they also include indications of text size, font type etc. I imagine that having all this extra information provided would quickly become tiresome for the user. It appears such schemes are intended for specific tasks such as proof reading.
Window Eyes has similar functionality to provide indication of color,style,font and size, called ‘Attribute Changes’. It is an item on the ‘screen’ menu. It does not appear to work on web pages using the keyboard to access content, but moving the mouse over bolded and italicised words on a web page does result in the format change being announced.
Using the semantic elements
em does not convey any useful information to users of JAWS or Window Eyes under typical browsing conditions. While it is good to know this, it is not a reason to not use these elements to convey meaning. Accessibility is not just about people with vision impairment, it’s about all user’s with disabilites, and web standards is not just about accessibility. This is merely another example where screen reader vendors are not serving their customers well.
As these tests only cover 2 of the screen readers available, it would be interesting to know if other products exhibit the same lack of support. so please test with your favourite screen reader and leave a comment with the results.