In a calendar I use abbreviated date/time formats. To make it screenreader-friendly I use the time element, as recommended in a lot of articles and posts. But somehow NVDA just ignores it.
For example, it reads "Fr. 13." no matter if I use the datetime attribute or not. And it always reads it wrong (13 franc, meaning Swiss franc).
<time datetime="2023-02-13T00:00:00+0100">
Fr. 13. 00:00 Uhr
</time>
Besides ISO Date I tried using different datetime formats. Makes no difference.
I know that there are workarounds. Using aria labels for example. But if possible I want it to work that way, because as far as I know it should and aria is to be avoided whenever possible.
None of the major screen readers specially handle <time> currently, as far as I know.
However, you should't be afraid about your text being not spoken exactly as you wish, and you shouldn't try to add a special label if it's just to enhance the pronunciation to your own liking.
Interpretation of dates, numbers, etc. and how they are spoken differ between screen readers and voices used. By adding a label to fix the pronunciation, you may help for one particular configuration, but do more harm than good for all other.
What you think should be spoken is maybe not what a VI user would like to be spoken in the same situation; the best is to make a real test with VI people to find out if it's a real problem or not.
As VI users, we are used to pronounciation issues, and we aren't stupid; we can most of the time still understand what you really mean anyway
Screen readers include pronunciation dictionaries allowing to customize what we don't like
Related
I'm using voice over and I'm trying to get it to read numbers as individual digits, for example if I have inputted 2000, voice over will read out "two thousand". I want the desired behaviour to read out "two zero zero zero".
my current input element looks something like this
<input class="some-class" id="some-id" name="some-name"
type="text">
I have tried setting the type attribute to type="number", type="tel" and adding a style attribute equal to style="speak:spell-out", but non of them worked.
When I separate the numbers with whitespace like value="2 0 0 0" it works, but of course, you can't expect the user to do this.
I understand there may be a way to do this using javascript, but the solution can not contain javascript in the browser due to business requirements.
Any suggestions?
You shouldn't try to force a particular pronunciation or digit grouping.
Add spaces if grouping has a particular importance or meaning.
Take the base principle that numbers shouldn't be read differently by a screen reader than it is presented.
If digits must be separated in a particular way, add spaces, dots, dashes or another separation character.
Conversely, if there's no spaces, there's no special need to absolutely read a number digit by digit.
That's quite simple.
You shouldn't force the screen reader to read something in the way you view it yourself.
Other people may not have the same vision as you. Concerning numbers, some people will prefer to read digit by digit, but others will prefer having them grouped by two, three or four, for their ease of reading, writing and memorizing. Their screen reader is normally configured accordingly.
If a given grouping is important, then groups must be separated with spaces or other characters. If there's no separations, then it implicitly means that grouping has no particular importance.
Note that screen readers always give the possibility to read numbers digit by digit, if the user wish to do so. It is usually not the default.
Reading numbers digit by digit is usually done only for very big numbers (billions), or when mixing digits and letters.
Additionally consider that:
Different screen reader users have different preferences, and accessibility speaking, it's generally a bad idea to go against preferences or common defaults
There are several screen readers, and a lot of different voices in many languages; all potentially behave in slightly different way when reading numbers, and any small change in order to tweak it might create more problems than solve.
Screen reader users are used to pronunciation quirks, and they can fix them using personal dictionary
Screen readers are nowadays not that bad on deciding whether they need to read numbers at a hole, in groups, or digit by digit.
So, avoid deciding a particular grouping or pronunciation. It's a bad idea, and anyway technically perilous.
I understand there may be a way to do this using javascript, but the solution can not contain javascript in the browser due to business requirements.
You tried HTML and CSS and you can't use Javascript. Screenreaders use the Accessibility tree. They do not use CSS, there's no instruction to tell them to spell the text. They might choose to spell some abbreviations while reading some acronym. This is screenreader choice.
Screenreader users are used to ear numbers as strangely as they come and if they want them to be read char by char they have the appropriate shortcut to willingly spell them.
I'm trying to improve screen reader support on our webapp, but I'm struggling a bit with what the best practice is for our buttons. Our current pattern looks something like this
If I focus on the button, should the screen reader say...
...Choose file, required?
...Upload personal letter: choose file?
...Upload personal letter: choose file. Allowed filetypes: doc, docx. Required?
We're currently going for the more talky version, but our team has limited experience with screen reader users and how they're used, so a push in the right direction would be very helpful. Thank you. :)
There is no real rule. It should be fine as long as indications are clear enough for the user.
In fact, it depends a lot on how you are used to your screen reader, Internet and your device in general:
Advanced users tend to prefer shorter labels and may be annoyed by longer ones.
Beginners may not understand if the label is too concise
Beginners may also be overflowed if the label gives too much extra information, or don't understand if the vocabulary is too technical
Screen readers have many options allowing you to decide what to say and what not to say. For example, Jaws calls that verbosity and there are 3 general levels that are further customizable.
Sadly, on the web, you can't determine the selected level, nor adapt the markup knowing that this element is only spoken in advanced or intermediate mode (this can be further highly customized anyway)
So the best is probably the middle option: be not too concise, but not too verbose either.
I'm a screen reader user myself; as an advanced user, regarding your propositions; I would say:
The second gives more confidence on what you expect exactly than the first one. If there are several files to upload, for example a cover letter + a CV + a photo, it's very important to have the information, so that there is less risk to mess up, i.e. upload the photo in the CV field.
If there are several fields with the same label that are labelled the same, it's hard to know which is which.
Indicating the allowed file types and other requirements of that kind is very good, but it is probably better placed outside the label.
Remember that the entire label is spoken again each time you tab into the field. If there are 5 fields with the same information, or if the form is complicated and you must go back and forth several times, it's annoying to hear many times the same.
So, I would go for a variation on the second one: "upload personal letter, required".
And indicate somewhere else in the page technical constraints like file type, size, etc. because it's still a very good idea.
Note that the "required" information can be left out from the label if you put the required and aria-required attributes on the field. It's the recommanded way to indicate that a field is required.
Tl;DR: Keep it concise.
If you want to convey some additional info like allowed file types, sizes, "no viruses please" etc., do not put this on the button itself. Prefer, for example, aria-describedby and make a separate control describing all those things, visually connected to the button (say, to the right of it).
We, I mean screen reader users, often navigate by items and do other weird stuff like invoking list of all buttons on the page (even Narrator nowadays started supporting such things), so if the button label is too long, it would be irritating too shortly.
I have the following header
<h1>ADD MONEY</h1>
and it is being read by VoiceOver as
a-d-d money
whereas if I change the text to lowercase it will read it properly as "add money". Do you have any suggestions? I have already tried using the aria-labelledby with no luck!
I recommend developers avoid trying to control screen readers in this situation. Some reasons:
Screen reader users are (typically) well accustomed to quirks like this, and will understand common words like "add" being spelled out. What can seem like a huge problem to developers (and QA testers) may actually just be minor issue for people who use screen readers all day long. Longer or uncommon words may be more of a problem with capitals, but there's no threshold.
It varies between different screen readers, and may come down to which voice (or text-to-speech engine) is being used. Words that are capitalized may be spelled out in one screen reader, and announced as a word by another. It's too much for most developers to worry about.
Some screen readers use different approaches with capitalization, for example announcing "cap" or changing pitch.
Some screen readers offer user settings for these. In my view, this is the main reason for developers to avoid micro-managing the screen reader experience - we may inadvertently get in the way of user preferences.
All of this may change as in the future, as speech engines and assisitive tech evolves. Attempting to control the announcements today may interfere with assistive tech capabilities in a few years time. WCAG guideline 4.1 states: "Maximize compatibility with current and future user agents, including assistive technologies" (emphasis mine). I interpret this as meaning that it's not worth attempting to micro-manage minor quirks like this in the short term.
Some answers here suggest the use of a CSS text-transform: uppercase. That's a good approach, but it also has inconsistencies between different screen readers. In an ideal world, the raw text and the text-transform could both be passed to assistive tech, to provide better information to speech engines, and also respect user preferences. We're not there yet, but it's being discussed by browser implementers - see this discussion in the Chromium bug tracker for extra detail: Honouring text-transform styles in the a11y tree?
Another suggested technique is to use a lower-case aria-label to duplicate the visible text, but force browsers to pass the lower-case version to assistive technology. For example <button aria-label="add money">ADD MONEY</button>. This may work quite well in many cases, but it's an example of how developers could get in the way of user preferences. For example, users who want their screen reader to change the speaking pitch for capitals will miss out here. A screen reader's primary job is to convey what's on the screen, including capitals. The lower-case aria-label technique is at odds with that, in my opinion.
A discussion about all-caps (in a Drupal CMS issue) has some interesting contributions from screen reader users:
Readability problem with all-caps text in core themes.
Leave the markup as lowercase, but use CSS to only change the text to uppercase visually via text-transform.
Then add an aria-label of "add money".
h1 {
text-transform: uppercase;
}
<h1 aria-label="add money">add money</h1>
I am attempting to make a site a bit more screen reader friendly and in testing I noticed that a common pattern is quite annoying on a screen reader - the site is using a vertical line / pipe character as a separator in the <title> tag (e.g. <title>Page Name | Site Name</title>). When I use VoiceOver as a screen reader to do testing it is read as "Page Name Vertical Line Site Name" which sounds especially odd with the particular title of the site.
What are the best accessible alternatives to the pipe that also have no negative effect on SEO? I've tried a <title>Page Name - Site Name</title> and <title>Page Name · Site Name</title> and they work okay, but I afraid they might have gotchas (e.g. reading as 'dash' or 'ampersand m i d d o t semicolon') on some edge case or causing chaos with SEO. Is there an accepted best practice for this?
The pronunciation of punctuation or special characters varies by screen reader, so there is no optimal choice. While it is true that “vertical line” sounds odd, it’s an oddity that screen reader users are accustomed to, since the “|” is widely used—not that much in title elements, rather in link lists and other contexts. The use of an en dash “–” might help, as it is a normal punctuation character and might be just ignored or even handled in an advanced way (e.g., a pause followed by raised tone). On other other hand, a comma “,” or a colon “:” might do the same thing, or do better.
It is very unlikely that such choices have any impact on SEO, since search engines generally ignore punctuation and special characters. (They might notify some special characters in some contexts, e.g. distinguishing between C and C++.)
Depending on context and context language, you could also consider using purely verbal expressions, e.g. in English using “of” instead of a separator character. “New products of ACME Corporation” sounds better than “New products | ACME Corporation” (though the latter is in no way wrong). This may have a minor impact on SEO, since search engines may treat even small words like “of” as significant; but this would not matter much, due to the way people write things in search boxes.
Using either a hyphen, or comma will have no effect on the site's SEO ranking.
But shorter titles often get more clicks from search (my own impression, backed by some data below), so think if you really need the site's name on every page?
Also, keep your title around 55 characters or so for best results in Google, the character count is trickier than it used to be, see http://moz.com/blog/new-title-tag-guidelines-preview-tool for a detailed explanation of some recent changes by Google. The current length is actually determined by pixel counts, not characters.
See this experiment for PPC CTR based on title lenghths: http://danzarrella.com/ppc-ad-line-lengths-and-clickthrough-rates.html# (not SEO, but correlates with my own experience in organic results).
I'm wondering if it's a bad idea to use weird characters in my code. I recently tried using them to create little dots to indicate which slide you're on and to change slides easily:
There are tons of these types of characters, and it seems like they could be used in place of icons/images in many cases, they are style-able and scale-able, and screen readers would be able to make sense of them.
But, I don't see anyone doing this, and I've got a feeling this is a bad idea, I just can't decide why. I guess it seems too easy to be true. Could someone tell me why this is or isn't okay? Here are some more examples of the characters i'm talking about:
↖ ↗ ↙ ↘ ㊣ ◎ ○ ● ⊕ ⊙ ○ △ ▲ ☆ ★ ◇ ◆ ■ □ ▽ ▼ § ￥ 〒 ￠ ￡ ※ ♀ ♂ &⁂ ℡ ↂ░ ▣ ▤ ▥ ▦ ▧ ✐✌✍✡✓✔✕✖ ♂ ♀ ♥ ♡ ☜ ☞ ☎ ☏ ⊙ ◎ ☺ ☻ ► ◄ ▧ ▨ ♨ ◐ ◑ ↔ ↕ ♥ ♡ ▪ ▫ ☼ ♦ ▀ ▄ █ ▌ ▐ ░ ▒ ▬ ♦ ◊
PS: I would also welcome general information about these characters, what they're called and stuff (ASCII, Unicode)?
There are three things to deal with:
1. As characters in a sentence/text:
The problem is that some fonts simply do not have them. However since CSS can control font use you probably will not run into this problem. As long as you use a web safe font, and know that that character is available in that font, you should probably be okay.
You can also use an embedded font, though be sure to fall back on a web safe font that contains the character you need as many browser will not support embedded fonts.
However sometimes certain devices will not have multiple fonts to choose from. If that font does not support your character you will run into problems. However depending on what your site does and the audience you are targeting this may not be a problem for you. Not to mention that devices like that are very old, and uncommon.
All in all it was probably not a good idea a handful of years ago, but now you are not likely to have problems as long as you cover all your bases.
It is important however to point out that you should never hard code those characters, instead use HTML entities. Just inserting those characters into your code can lead to unpredictable results. I recently copied some text from Word directly into my code, Word used smart quotes (quote marks that curve inwards properly). They showed up fine in Notepad++, but when I viewed the page I did not get quotes, I got some weird symbol.
I could have either replaced them with normal quotes " or with HTML entities to keep the style “ and ” (“ and ”).
Any Unicode character can be inserted this way (even those without special names).
Wikipedia has a good reference:
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
2. As UI elements:
While it may be safe to use them in many cases, it is still better to use HTML elements where possible. You could simply style some div elements to be round and filled/not filled for your example.
As far as design goes they are really limiting, finding one that fits with the style of your page can be a hassle, and may mean that you will definitely need to embed a font, which is still only supported by the latest browsers.
Plus many devices do not support heavy font manipulation, and will often display them poorly. It works in the flow of your text, but as a vital part of the UI there can be major problems. Any possible issue one of those characters can bring will be multiplied by the fact that it is part of your UI.
From an artistic stand point they simply limit your abilities too much.
3. What are you doing?
Finaly you need to consider this:
Text is for telling
Image is for showing
HTML is for organizing
CSS is for making things look good while you show them
JavaScript is for functionality
Those characters are text, they are for telling someone something. So ask the question: "What am I doing?" and then use what was designed for that task. If you are telling use them, if you are showing use Image, or CSS.
I've seen this done before (the stars) and I think it's an awesome idea! It's also becoming quite popular to use a font (with #font-face) full of icons, like this one: http://fortawesome.github.com/Font-Awesome/
I can't see any downside to using a font like "font awesome" (only the upsides you mention like scalabilty and the ability to change color with CSS). Perhaps there's a downside to using the special characters you mention but none that I know of.
The problem with using those characters is that not all of them are available in all fonts used by all users, which means your application may look strange, or in the worst case be unusable. That said, it is becoming more common to assume the characters available in certain common fonts (Apple/Microsoft's Arial, Bitstream Vera). You can't even assume that you can download a font, as some users may capture content for offline reading with a service like Instapaper or Read It Later.
There are a number of problems:
Portability: using anything other than the 7-bit ASCII characters in code can make your code less portable, as recipients may use the wrong encoding. You can do a lot to mitigate this (eg. use UTF16 or at least UTF-8 encoded files). Most languages allow you to specify strings in characters using some form of escape notation (eg. "\u1234" in C#), which will avoid the problem, but loses some of the advantages.
Font-dependency: user interface elements that depend on special characters being available in a font may be harder to internationalize, since those glyphs might not be in the font that you want/need to use for a particular audience.
No color, limited choice of art: while font glyphs might seem useful to a coder, they probably look pretty poor to a UI designer.
The question is very broad; it could be split to literally thousands of questions of the type “why shouldn’t I use character ... in HTML documents?” This seems to be what the question is about—not really about code. And it’s about characters, seen as “weird” or “uncommon” or “special” from some perspective, not about character encodings. (None of the characters mentioned are encoded in ASCII. Some are encoded in ISO-8895-1. All are encoded in Unicode.)
The characters are used in HTML documents. There is no general reason against not using them, but loads of specific reasons why some specific characters might not be the best approach in a specific situation.
For example, the “little dots” you mention in your example (probably not dots at all but circles or bullets), when used as control elements as you describe, would mean poor usability and poor accessibility. Making them significantly larger would improve the situation, but this more or less proves that such text characters are not suitable for controls.
Screen readers could make sense of special characters if they used a database of various properties of characters. Well, they don’t, and they often fail to read properly even the most common special characters. Just reading the Unicode name of a character can be cryptic or outright misleading. The proper reading would generally depend on meaning and context.
The main issue, however, is that people do not generally recognize characters in the meanings that you would assign to them. How many people know what the circled plus symbol “⊕” stands for? Maybe 1 out of 1,000, optimistically thinking. It might be all right to use in on a page about advanced mathematics or physics, especially if the notation is defined there. But used in general text, it would be just… a weird character, and people would read different meanings into it, or just get puzzled.
So using special characters just because they look cool isn’t a good idea. Even when there is time and place for a special character, there are technical issues with them. How many fonts do you expect to contain “⊕”? How many of those fonts do you expect Joe Q. Public to have in his computer? In this specific case, you would find the font coverage reasonably good, but you would still have to analyze it and write a longish list of font names in your CSS code to cover most platforms. In the pile of poo case (♨), it would be unrealistic to expect most people to see anything but a symbol for unrepresentable character. Regarding the methods of finding out such things, check out my Guide to using special characters in HTML.
I've run into problems using unusual characters: the tools editor, compiler, interpreter etc.) often complain and report errors. In the end, it wasn't worth the hassle. Darn western hegemony, or homogeneity, or, well, something!