I'm using Windows Narrator and a version number like 2.3.96 is being reader as a date "2nd March, 1996". How do I handle version numbers for screen readers? I see some answers suggested using a label and spell out the dots, like: aria-label="2 dot 3 dot 96". Is there a better way to do this?
There are already several similar questions on stackoverflow and elsewhere about numbers and other things that aren't pronounced as the page writer expects.
The same answer applies to version numbers interpreted as dates: you'd better do nothing and write it without anything special.
The problem is that the pronunciation of numbers depends on many layers:
The browser and its way to expose accessibility tree.
The OS, the screen reader and its settings. For example, Jaws offers many options that can change how numbers and dates are interpreted and spoken out.
The voice used. The same screen reader, on the same OS, with the same browser, but with different voices can indeed read the same text very differently.
You may try several things, like separating it in a different <span>, adding or removing spaces, writing "dot" via aria-label, etc.
However, by doing so, you are very likely to improve the pronunciation for some users, while degrading it for most others. The combinations of OS, browsers, screen readers, and voices are too huge to be able to test everything.
So the best is to keep pragmatic and don't do anything special. Keep your version number written as it is usually done everywhere.
Screen reader users are generally used to such pronunciation quirks and can, if necessary, adjust options and set up dictionaries.
Short Answer
Use <p aria-label="Version 2 point 3 point 96">Version 2.3.96</p>, this will get parsed correctly in most popular screen readers. Make sure there are no <spans> splitting the version number from the text, use an aria-label as overkill / a backup.
Long Answer
Normally I would advise to never interfere with the way a screen reader pronounces things, as #QuentinC has suggested.
However in this circumstance I would say that you do want to try and fix this problem, as hearing a date read where there should be a version number could be very confusing (was it the date the software was written, is it the date the company was formed? Who knows!).
This is a parsing problem in the screen reader, very different from problems most people have where they don't like the way something is read, please only follow the advice below for this one example only.
Fix one, change your markup.
You didn't add your markup but the below explanation is based on my testing.
This problem will actually fix itself (at least in JAWs, NVDA and VoiceOver from my testing) by simply adding 'Version' before the version number.
My guess is you have the version number in a format similar to the following:
<p>Version <span>2.3.96</span></p> or <p>2.3.96</p> without the word 'version'.
By removing the <span> in the first example JAWS, NVDA and VoiceOver read the following correctly in my testing:
<p>Version 2.3.96</p>
Once the <span> is added around the version number the context of the numbers is lost (text within <span> elements is evaluated on it's own) so a screen reader will try and parse it on it's own, without any context, and decide it is a date.
Surely using aria-label will fix it though?
Also aria-label will probably not work on static elements (<div>, <span> etc.) that do not have a role that indicates they are an active element, so odds are it will not work anyway for you.
For that reason I would not recommend trying to fix this problem with aria-label alone, however adding it for the screen readers that do take it into consideration is a step that would not hurt.
This is the only time I have ever recommended interfering with how a screen reader talks, please do not take this as a step to solve other pronunciation problems as this is a parsing problem not a pronunciation problem.
Taking that into account I would recommend you use the following:
<span aria-label="Version 2 point 4 point 99">Version 2.4.99</span>
With either a <span>, <p> or other content block surrounding it.
Related
I've been playing around a little with both VoiceOver and the Text to speech functionality on my mac. I've noticed a few differences in the way numbers and punctuation is pronounced. For example the sentence "the year was 1978", is read out perfectly when I highlight it and use text to speech. With Voiceover however, it reads "the year was one nine seven eight".
How can I tell screen readers that I want something pronounced in a certain way? Is there ARIA attributes I can add for this kind of behaviour?
It is not just dates and years but prices and punctuation as well (and probably a lot of other things!).
I don't think you can control speech output with the APIs currently available.
I assume that you are talking about HTML page as you referenced ARIA attributes. WAI ARIA does not have attributes to control the screen reading. I believe W3C is coming up with Text-to-Speech synthesizing markup language (SSML) to provide better control over speech output.
If your issue is related to native Mac OS application screens, you can check out Apple's Speech Synthesis APIs.
The Apple VoiceOver as well as Microsoft Windows Narrator are very basic screen readers with little or no intelligence built in. Apple's text-to-speech is little advanced but it still lags behind commercial screen readers like JAWS. But good thing is that users with impaired vision typically have good screen readers which can read your content appropriately.
Common speech synthesizers allow their clients to configure whether numbers will be read as words or spelled-out (both on a global default and per-specific-case setting). E.g. Apple's speech synthesis API propagates this possibility using the NSSpeechNumberModeProperty property. VoiceOver users can then set only global (or at best per-app) default in VoiceOver Utility > Verbosity > Text > "Read numbers as:".
Now if you want to influence how screen readers should pronounce numbers in web content, there is a CSS Speech Module. It defines the speak-as property, which can have a value of normal or digits.
However whether such CSS value will be respected by a combination of particular version of particular screen reader and particular version on a particular browser running of particular version of particular OS is a thing you have to try yourself. The accessibility APIs on OS X currently have no way to specify pronunciation of digits in the returned strings, so if it worked for WebKit, it would have to be using some private extension to those public accessibility APIs. I just tried on OS X 10.9.3 and this does not work.
If I had to guess, you would be lucky to find a combination of screen reader / browser / OS where this would be implemented as of now. But this is just speculation.
I work on a multilingual website that will contain many languages that are not normally written, and I wonder if there are any ways to get this working for people using screen readers? Is it possible to give a text an attribute to make the screen reader play a prerecorded sound instead of trying to read the text by itself?
The whole menu system will be translated into the languages that are not supported by any screen readers.
The two popular screen readers are JAWS and NVDA. You can see what languages JAWS supports, 28 in total. NVDA supports 43 languages (I couldn't find a list).
I wonder if there are any ways to get this working for people using screen readers
There is a few things you could do that come to mind:
Declare the language of the page via the <body lang="">, so that if the screen reader happens to know how to interpret it, it uses that language
Put links to common language translations near the top of the page so if somebody lands on a random page from a search engine hit, they can change languages quickly.
Is it possible to give a text an attribute to make the screen reader play a prerecorded sound instead of trying to read the text by itself?
The lang attribute makes the screen reader switch to another language if it understands it. You can provide links to audio files to be listened to, I would be a little cautious with providing your own audio player. Not all audio players are accessible, the two common issues with these are the controls are not labeled and they cause focus trap.
Unlabeled controls make the assistive technology say "unlabeled" or something similar, so you cannot tell the buttons apart from each other. Focus trap effects people who use the keyboard to navigate a page, this is usually using the Tab key, and instead of getting out of the audio player, it goes to the first element of the audio player again.
From Comments
How I can make the screen reader play these files instead of trying to read the text.
The only thing you can do is use ARIA to hide the content via the aria-hidden='true' attribute. You can check my answer about aria-hidden for more details. Essentially you would do something like:
<article aria-hidden="true">
<h1>Some Really cool language</h1>
<p>Blah blah blah</p>
<section aria-hidden="false">
<h2>Audio of language</h2>
<p>below is an audio sample of ____. Blah blah blah</p>
<p class="offScreen"><!-- it may be a good idea to put additional
info for people using assistive tech --></p>
<p>audio stuff</p>
</section>
<article>
CSS
.offScreen{
position: absolute;
top: 0;
left: -999px;
}
Ryan, I've seen this question asked elsewhere about "click" languages, as of southwestern Africa. So far as I know, there is no written alphabet that is intrinsic to these languages. Scholars might record the languages phonetically, but more common techniques involve adding exclamation points and perhaps other basic keyboard characters to indicate the vocalizations that cannot be conveyed by European alphabets. The Kx'a family of languages is one such group.
If you look for RFC 1766 on sourceforge.net, you'll find a list of 122 languages or variants of languages that map to specific values of the lang attribute. And RFC 1766 itself shows how to add Klingon and other "experimental" languages to the mix.
So there are several issues, it seems:
If a language has not yet been mapped, how does one create a mapping of its characters and groups of characters (its graphemes) to its sounds (its phonemes)?
Assuming that's all that is required, how does one get that mapping associated with a new value for the lang attribute? (To get that new value, RFC 1766 says to create, complete, and submit a simple form. But, given that the document called RFC 1766 is 18 years old, how reliable is that information? And just where does the mapping of symbols to sounds fit into the picture?)
Ultimately, how does one get a screen reader to recognize that mapping and the corresponding value of the lang attribute?
My somewhat contrarian take: don't try to automatically replace the text with pre-recoreded content; instead focus on ensuring that the user is aware that both are available, and can access whichever is most appropriate for them based on the tools they have at their disposal.
Some more background context might help: from your description, it sounds like this is perhaps an academic or research site, that has fragments of text in these languages, with audio; but where the remainder of the site structure - headings and supporting narrative text - is in some 'well-supported' language (English, etc.)? (What is the encoding system used for this test?)
If so...
Be aware that a screenreader user does not typically read an entire page top-to-bottom in a completely linear fashion; they can browse the page using the heading structure. In a well-marked-up-page, the user has the freedom to skip over the portions that they are not interested in or which are not relevant to them. Focus on providing this flexibility rather than making (well-meaning, but potentially incorrect) policy decisions on behalf of the user.
Don't assume that a screenreader user is using speech in the first place; they could be using Braille, whether due to the fact that speech output is not an option for them, or simply because Braille is their preferred form of output.
Finally, don't assume that because a screenreader user can't hear the text properly (due to text-to-speech limitations), that the textual form of the content should be hidden from them entirely; they may still want the ability to cut-and-paste the characters that represent the text so that they can send them to a colleague, for example. Or, depending on the writing scheme used, a screenreader user may still be able to step through the characters letter-by-letter and have the words spelled out to them letter-by-letter - many screenreaders can call out non-latin characters by their Unicode name.
The issue here is less about JAWS and more about having a Synthesizer which speaks the language and can communicate with JAWS through a driver such as SAPI 5. Development of these languages for the various synthesizer companies can be costly, especially if there is not a good business case driving it such as GPS, ATMs, Call Centers, etc.
There are open source solutions such as eSpeak which you might look into as well. It is not the highest quality but could be an approach if you have access to developers willing to work on such a project.
As for the question regarding an API or method to communicate information to JAWS via prerecorded sound files of the web site? This is not really going to meet the need of the screen reader user who would have no way to navigate the information or interact with it using Links or form field elements. I really think the synthesizer development is the only solution unfortunately.
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
Since the control emits bizzare non-standard HTML, I'm wondering if it has any practical value.
The control emits font tags!
How are others dealing with it? Do you do some sort of RegEx replace on the text?
Or am I missing something?
Does it have a value? Yes. Is it practical? That depends. How much work are you willing to do to get something useful out of it?
I had to use the RTC to create a chat window for a chat app that was built on Jabber. I wound up having to parse every line of every chat message, check its textwidth, GREP out the bogus HTML (TextFormat and Font tags) while leaving the styling tags (bold, italic, etc.) then shift it onto a queue that would scroll upwards as new messages were sent and received. I had to keep an onscreen buffer of 200 of these lines (taking care not to delete partial messages at the end of the queue). I also had to plot where the emoticons — :) ;) :-) and the like — were located, find out their exact locations, and then draw the emoticon images onto a sync-scrolled Canvas that exactly matched the position of the chat output window. All this while keeping the text selectable and letting people copy and paste it, complete with emoticon tokens that reverted to whatever text smiley upon pasting into the input field.
Was this a lot of work? You bet it was. Was the product ultimately useful? I like to think so. It was pretty cool, in fact. And as it was one of the first Flex projects I ever worked on, it taught me a lot.
Do I wish Adobe supported real, non-gimped HTML? Absolutely.
Short answer: Getting something out of the RTC is a bitch, but probably still faster than doing anything similarly useful in Java or C++. YMMV.
Developing websites are time-consuming. To improve productivity, I would code a prototype to show to our clients. I don't worry about making the prototype comform to the standard. Most of the time, our clients would approve the prototype and give an unreasonable deadline. I usually end up using the prototype in production (hey, the prototype works. No need to make my job harder.)
I could refactor the code to output valid HTML. But is it worth the effort to output valid HTML?
It is only worth the effort if it gives you a practical benefit. Sticking to standards might make it easier to build a website that works across most browsers. Then again, if you're happy with how a website displays on the browsers you care about (maybe one, maybe all), then going through hoops to make it pass validation is a waste of time.
Also, the difference in SEO between an all-valid html website and a mostly-valid html website is negligible.
So always look for the practical benefit, there are some in some situations, but don't do it just for the sake of it.
Yes. It's hard enough trying to deal with how different browsers will render valid HTML, never mind trying to predict what they'll do with invalid code. Same goes for search engines - enough problems in the HTML may lead to the site not being indexed properly or at all.
I guess the real answer is "it depends on what is invalid about the HTML". If the invalid parts relate to accessibility issues, you might even find your customer has legal problems if they use the site on a commercial basis.
Probably not if you have a non-complying site to begin with and are short on time.
However, and you won't believe me because I didn't believe others to begin with, but it is easier to make a site compliant from the start - it saves you headaches in terms of browser compatibility, CSS behaviour and even JavaScript behavior and it is typically less markup to maintain.
Site compliance (at least to Transitional) is pretty easy.
Producing compliant HTML is similar to ensuring that you have no warnings during a compilation - the warnings are there for a reason, you may not realise what that reason is, but ignore the warnings and, before you know where you are, there as so many, you can't spot the one that's relevant to the problem that you're trying to fix.
If you use Firefox to view your web pages, you'll get a helpful green tick or red cross in the bottom right hand corner, quickly showin you whether you've complied or not. Clicking on a red cross will show you all of the places where you goofed.
Some of the warnings/errors may seem a bit pedantic, but fix them and you'll benefit in many ways.
Your page is much more likely to work with a wider range of browsers.
Accessibility compliance will be easier (You'll have 'alt' attributes on your images, for example)
If you choose XHTML as a standard, your markup will be more likely to be useful in an AJAX environment.
Failure to do this results in unpredictability.
One of the biggest problems with web browsers is that they have perpetuated bad habits (And still do, in some cases) by silently correcting certain markup problems, such as failure to close table cells and/or rows. This single fact has resulted in thousands of web pages that are not compliant but 'work', lulling their developers into a false sense of security.
When you consider how many things there are that can go wrong with a website, being lazy when it comes to compliance is just adding more problems to your workload.
EDIT: having read your original post again, I notice that you say you don't bother with compliance when working on a prototype, then you go on to say that you usually use the prototype in production - this means that it's not strictly a prototype, but a candidate.
The normal situation in such circumstances is that once the customer accepts a candidate, no time is allocated for bug fixing or tidying up, thus strengthening the argument for making the markup compliant in the first place.
If you won't be given time later, do it now.
If you are given time later, then you had the time to do it anyway.
If you want your sight to be accessible to people with and without disabilities, as well as external systems, then yes, you should definitely make sure you output valid HTML.
It's easy to test your HTML with automatic validators.
I'll add to what Mike Edwards said about legal ramifications and remind you that you have a moral obligation too :)
Why not write the prototype in valid (X)HTML in the first place? I've never found that to be more of an effort than using invalid HTML. Producing valid XHTML should be a trivial task. (On the other hand, producing semantically meaningful XHTML might be more taxing.)
In short, I see no advantage whatsoever in using invalid HTML for prototypes.
I honestly dont know why it is extra effort to do standards based HTML. It's not as if it's hard and you should be doing it as a matter of professionalism.
If you paid someone to build you a house and he cut corners out of laziness, that you didnt notice at the time, but in 10 years cracks appeared in your walls, would you be happy?
Valid HTML just to be able to have a badge on your site - no.
Having "valid HTML" in the sense of "HTML that works on every major browser or browser engine" - yes.
Absolutely. Invalid code can cause all sorts of weird behaviors, and errors which don't obscure those that do when you get a validation report.
Case in point:
A yellow background was spilling out of a list of messages and over the heading for the next list of messages - but only in Internet Explorer.
Why? The background was applied to a list item, but the person who wrote the page had written it as a single list with a heading in the middle. Headings are not allowed between list items and different browsers attempted to recover from it in different ways. Internet Explorer ended the list item (with the background colour) when it saw the start of the following item (after the heading), while other browsers ended it when they saw the end tag for the first list item.
It was the only validity error on the page, so it took only a couple of minutes to track down the problem and fix it.
Because, if you stick to standards, your work will be compatible in the future. User Agents will strive for standard compliance and their quirks non-compliance mode will always be subject to change. This is the way is supposed to be.
Unless you're into that whole IE8 broken standards perpetuation thing that they want to enable by default. -- that's another argument.
Webkit, Gecko, Presto? (is that opera's engine?), and the others will always become more compliant with every release.
Unless your html work is in a IE embedded browser control, then there's really no reason to output valid html as long as it renders.
In my opinion the key criterion is "fit for purpose" - If your clients want something for a small/internal market (and don't care if that alienates potential customers who have disabilities or use less-common browsers) then that's their choice.
At the same time I think it's our (as developers) responsibility to make sure they know the implications of their decisions - Some organisations will be bound by legislative requirements that websites be useable by screen readers, which typically means standards-compliant HTML.
i believe making valid html outputs wont hurt your development time that much if you've trained yourself to code valid html from the start. for one, its not that hard to know which tags are not allowed within an elementand the required attributes in a tag are sometimes the ones you'd really need anyway - i believe these are the main errors that makes your html invalid, so why not just learn them as early as now if you plan to stay on the web for long?plus outputting valid html can help boost your sites ranking
There are two rules for writing websites:
The site must work for your users.
The site must work for your users.
To meet the first rule, you have to code such that your site renders correctly when using Internet Explorer. Unless you have the freedom to alter your site design to use only those features that IE renders correctly, this means writing invalid HTML.
To meet the second rule, you have to code such that your site renders correctly when using screen-readers and braille screens. Although some newer screen readers can work with IE-targeted sites, in general this means writing valid HTML.
If you're working on a small project, or you're part of a large team, you can code a site that outputs IE-targeted HTML for IE, and valid HTML otherwise. But if you're taking on a medium-to-large project on your own, you have to decide which rule you're going to follow and which one you're going to ignore.
UPDATE:
This is getting voted down by users who think you can always get away with valid HTML in IE. That may be true if you have the flexibility to change your design to get around IE's shortcomings, but if a client has given you a design and you have to get it working, you may have to resort to invalid HTML. It's sad, but it's true, whatever they might think.