In a recent thread on the Web Standards Group mailing list, the question arose about whether Screen Readers support semantic HTML elements such as strong and em. The short answer for the two main screen readers JAWS and Window Eyes is no. Neither do they support i or 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.
UPDATE 28/01/10
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 strong, em, i, b, strike, and del HTML 4 elements. Window Eyes 5.5 and JAWS 8.0 were used to read the test document in Internet Explorer 7.
Results:
Using the default settings, neither screen reader indicated the presence of any of the elements tested.
| element | JAWS | Window Eyes |
|---|---|---|
| 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 strong or 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 strong or 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. Refer to update at start of article.
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.
Conclusion
Using the semantic elements strong and 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.
Comments
VoiceOver on OSX does recognise inline elements, but just stops when it hits them:
https://alastairc.ac/#inline-elements
Hi Steve, thanks for testing this out and publishing the results. I’m not at all surprised by the lack of differentiation of emphasised, bold, italicised or strongly emphasised text, the general low quality of web markup has perhaps rendered any meaning useless. I am disappointed by the lack of support for ins and del, again this is understandable because those elements aren’t commonly used on websites.
I’d certainly like to see better support for structured markup in screen readers and accessibility architectures. Headers navigation is a good example of a screen reader using structured markup to improve usability.
Thanks for publishing these results.
Thanks for confirming my suspicions and publishing your findings.
Thanks for that Steve, it’s interesting to know and I particularly agree with your point about accessibility in the conclusion. Accessibility also applies to the average web user – the ones who aren’t using screen readers.
I am shocked and appalled.
AlastairC:
Thanks for the voiceover results, the behaviour it exhibits does not appear to be very useful.
Isofarro wrote:
Good point Mike it’s not all bad news, Screen Readers do make use of many HTML structures, such as headings, lists, data tables, paragraphs and abbreviations, to provide navigation and convey meaning to user’s.
Mike and Thierry:
No problem!
Matt
Matt wrote:
thanks for your comments. I think you may have misinterpretated what i wrote or I didn’t make myself clear, I have added a clarification in the post. I believe that web accessibility is about ensuring access to all users with disabilities, not just user’s with vision impairment, but web accessibility is only a subset of web standards.
Good stuff Steve. This is a user agent issue, rather than being any fault in the mark up. It could probably be relatively easily resolved by the makers of all our favourite screen readers. This fuctionality could be added in a high level way to determine how the UA outputs existing mark up via the current verbosity settings. More verbose, could be set to output
strongorem‘d content in a different voice (slight raising in pitch would do it for starters). Shouting wouldn’t 🙂This would make it easier for end users as presenting them with the choice of “do you want HTML content with strong, or b or em etc” announced would not be ideal as most end users are not developers so they would not have a clue what these things mean, and neither should they.
It’s probably a case that screen reader users have gotten by for years without these features hence the lack of their addition at this stage.
Steve: JFW (and I suspect WE too) recognises all of those elements, it just doesn’t prompt the user as to their presence with default settings. you can query JFW on the font atributes of the text with focus (jfw key +f) and all of those attributes are identified all be it not always with the strictly accurate names, EG ‘strong’ ‘bold’ and ’emphasis’ are all called ‘bold’ by Jaws. obviously querying the attributes of each and every word is tiresome and not something a user is likely to do but this does clarify that the screenreaders do recognise the attributes, they just don’t prompt the user as to their presence by default. however, select the ‘proof reading attributes and font info’ sound scheme and they are differentiated, jfw key +alt +s to list sound schemes. on my configuration words with different attributes ae read in a different voice. this doesn’t obviously tell you why a different voice is being used, you need to look at the particular sound scheme configuration to see what the given voices denote. Seems like a step back on some of the attributes as JFW certainly used to announce ‘strong’ by default (for both strong and em tags) in previous versions. I think this was the case in v7 – I’m currently using v9.
Hi Adrian, thanks for your comments. I tested in JAWS 6.2 and 7.0, same result, no indication by default. I understand what you are saying about JAWS recognising font styles such bold and italic. There is a difference between actually supporting the HTML elements specifically and picking up their visual styles. For example the HTML heading (
h1toh6) elements are recognised and reported to user’s by JAWS regardless of the way they are styled visually. Theemandstrongelements are not supported in this way, they are only reported (if the user has modified their scheme) due to their default visual styles in browsers.Setting JAWS to read with speech settings set to Classic-Attributes makes JAWS announce changes from normal to bold etc. and I prefer to use this for proof reading documents. Some might prefer these changes to be distinguished via JAWS voice settings (eg. “Proof reading – attributes” as suggested by Adrian). On the Web, even table header cells marked up with TH are distinguished with these speech settings. Ocasionally one encounters table header cells incorrectly marked up with h1 … h6 or STRONG and these too are read in the same manner as header cells correctly marked up as TH. In conclusion, as Steve points out, a JAWS user cannot really distinguish between bold or italicized text and text marked up with STRONG or EM. But is this not true for all users? Can sighted users make this distinction?
Hi Sailesh, thanks for contributing to this discussion.
Sailesh wrote:
Your observation is true, sighted users see the italicised or bolded text, but don’t know necessarily that they are marked up using
strongorem, they infer semantics from the text style, but these elements can be styled differently using CSS. For example through the use of colour, size or position, rather than italicisation or boldness. How is the screen reader going to convey the meaning of emphasisemor stronger emphasisstrongreliably unless it actually recognises the HTML element’s rather just a visual style that is loosely associated with them.This has been an issue for some time.
It seems that only the most commonly used structures are implemented.
Recently, we discovered that the full “HTML Entity Reference” set is not supported either.
It came to light when asked to investigate the reason why “≥” (the reference for “greater-than or equal to”) wasn’t recognized properly by JAWS. It was spoken as “equals” as were similar entities.
It seems like a rather “esoteric” issue but, when you rely on these symbols for presentation of statistical data, you run into a real problem. It is standards compliant, valid, code but relays erroneous information in one of the two most popular screen readers.
Contacting Freedom Scientific revealed that this wasn’t to be addressed in an upcoming release.
Testing with Dolphin Software’s Supernova revealed better results. The entity reference was spoken properly.
Further testing is not planned at this moment due to time constraints and resources.
Entity reference for HTML Latin-1 Character Entities Reference
Sorry to double post.
I didn’t realize that this blog would render the entity as the symbol. Should have used “code” encapsulation. The entity reference is
≥.I also should have noted that you can add the references to the JAWS dictionary but you have to code it something like
/8805. It would be a real chore to enter each reference this way.So, if anyone knows a way to “bulk add” a list to the JAWS dictionary, I’d appreciate the help.
Thanks.
Hi Steve, no worries about the double post.
Steve Buell wrote:
You can edit the dictionary files (.jdf [job definition format]) in a text editor and add them that way. The .jdf files can be found in “C:Documents and SettingsAll UsersApplication DataFreedom ScientificJAWS8.0SETTINGSenu” for windows XP. the default dictionary file is named ‘DEFAULT.JDF’ strangely enough.
and , 2 tags that semantically describe the content contained within them and have been around since the dinosaurs. Its pretty sloppy and not acceptable for screen readers to ignore these elements.
One day we will have the aural browser common place with CSS speech support, but until then people will go on having to suffer what’s currently available.
I would have thought that the audio stylesheet was the best place to control the audio emphasis ( media=”audio”).
W3C recomends stuff like
H1, H2, H3, H4, H5, H6 {voice-family: paul;
stress: 20;
richness: 90;
cue-before: url("ping.au")
}
so, presumably, you can do the same for things like strong and italic.
Has anyone tried this?
Richard
I think it’s quite sad that JAWS as late as version 8 doesn’t support such basic semantic HTML elements by default. It certainly won’t impact upon my usage of these elements but it’s a pity that many screen readers won’t “get the benefit” and that the developer’s efforts to potentially enrich the user’s experience are, once again, stalled by user agents that simply ignore basic markup.
Just out of curiosity, how are blockquotes handled by default? This is another area where I’d have thought that a change of voice, or inflection, would be useful.
@Ricahrd Warren:
Support for aural CSS within screen readers generally is poor to non-existent.
Steve, very useful information; thank you for publishing this.
In addition to the perceived oversight in JAWS and WE, this underscores the lack of true semantic indicators in much of HTML. What versus indicates — actually means — could vary. WAI-ARIA aims to bridge this semantic gap by defining roles, states, and properties that may readily be surfaced to the user agent and assistive technology.
Could the reasons be that user agents do not fully utilize semantic markup is because of tag soup? What logic is there behind non-existant implementation of aural style sheets within user agents? It seems that aural style sheets could overcome issues of the former. Accessibility is a tough thing particularly without sufficient input from users who rely upon accessibility.
Mel Pedley wrote:
JAWS announces “blockquote” at the start and end “blockquote end” of blockquotes. This notification can be disabled in the HTML options dialog. Users can also bring up a list of blockqotes in a page using CTRL+ INSERT + Q. or navigate between blockquotes using the Q key. Window Eyes has similar blockquote support to JAWS.
In defense of of assistive/adaptive technologies (AT), they have to make real choices in what to support.
The market for these technologies is comparatively low in relation to other user agents.
The developers of commonly used screen readers, and other AT, have fewer resources to dedicate to development and always have to catch up to what is most “popular”.
Catching up to AJAX, and other RIA constructs, is going to be a challenge that will take focus away from other things.
The majority of publishers of web content know very little about structure, semantics, or standards.
AT vendors don’t have the latitude to chase these “ghosts”.
Hi Steve, I have to diagree with your defense of the AT vendors on this. The
strongandemelements are not “ghosts” as you characterise them. It is reported from a study of 1.27 million URis that thestrongelement is used on approximately 25% of pages and theemis used on around 10% of pages. (Source: Coding practices of web pages).Furthermore for web accessibility to succeed there it has to be a form of social contract between author’s, user agent vendor’s and user’s. Author’s need to code using web standards and with web accessibility in mind, vendor’s need to support web standards and sepcifications and user’s need to make reasonable efforts to understand the software they use, so they can benefit from the efforts of the author’s and vendor’s.
The
strongandemelements have been in the HTML 4.01 specification for almost 10 years, and it is not good enough that AT user agents do not support them.Sorry Steve.
I didn’t mean to imply that
strongandemwere “ghosts”.I was referring to the more esoteric mathematical entities, the “equal to or greater than” references, I had noted in my previous post(s).
The
strongandemelements are more common and do indeed give important contextual meaning.My apologies for any confusion I my have caused.
hey steve, no need to aplogise, debate is good!
I’m not too surprised at AT software not distinguishing between normal text and [strong] or [em]phasised text – but I am absolutely staggered that it doesn’t in any way draw attention to [b]old or [i]talic text. These methods of highlighting text have been around since the dawn of time, and for screen readers to blithely ignore this and read them as though they were not in any way marked is appalling.
I’m now wondering if I need to frantically write aural.css for all my websites with
strong { pause:20%; volume:120%; }
em { pause:10%; volume:110%; }
It depends on the software that you are actually using. In testing several for my mother, I had varying results across different web pages. I never did check the underlying code to see what was included as part of the CSS or HTML. The pages were considered “visually impaired friendly”. Ultimately, we settled on JAWS as it seem to provide her the most functionality and the best overall results.
Steve,
Any stats on how often del or strike elements are used in comparison to strong and em? I would guess that they aren’t used much, but the impact of them not being understood by screen reader software is probably greater. To me del or strike has a clear semantic meaning that this is something that has been changed or removed from the text but I want you to know that it was there originally. It could be in the context of formal amendments but is probably generally used more for ironic purposes (if that’s the right word).
Of course there is another accessibility difficulty with using del or strike and that is whether it becomes unreadable. depending of course on style.
Steve, very useful information, thank you for publishing this. I do like to see better support for structured markup in screen readers and accessibility architectures.
Good stuff Steve.
This is a user agent issue, rather than being any fault in the mark up. It could probably be relatively easily resolved by the makers of all our favourite screen readers. This fuctionality could be added in a high level way to determine how the UA outputs existing mark up via the current verbosity settings.
More verbose, could be set to output strong or em‘d content in a different voice (slight raising in pitch would do it for starters).