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>
Related
I currently have a simple bit of markup on my site, and can't seem to get a screen reader to read it. Am I missing something?
<section aria-label="This is the text I want to be read "></section>
I've also tried:
<section aria-description="This is the text I want to be read "></section>
The section isn't tabbable as such as its not a link, not sure if that's connected to the problem, but my understanding of whether the screen reader should or should not be reading something is sketchy at best.
Screen reader in question, if it matters.
https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn
Any help appreciated.
It might depend how you are navigating with the screen reader. Since the <section> is not a keyboard focusable element, I'm assuming you have some text content in it? Most screen readers will let you navigate to all elements on the page, including plain text, using the down arrow. The down arrow essentially walks the DOM. (It actually walks the accessibility tree but for now think of it as walking the DOM.)
If you can navigate to a focusable element before the <section> using the tab key, then you can start using the down arrow to get to the section.
With NVDA, I heard "This is the text I want to be read, region". Note that it's saying "region" because a <section> element has a default role of "region".
With JAWS, it did not read the aria-label, but that's because of the JAWS default verbosity settings which does not include regions. If you change your verbosity setting from the default "medium" to "high", then you will hear the section label when you arrow down to it. (Or you can configure your current verbosity setting to include regions.)
With JAWS, you can also navigate by landmarks. Since a <section> has a "region" role, and a region is a landmark, I can navigate by landmarks with JAWS using the R key and when I do that, I hear "This is the text I want to be read region", regardless of my verbosity setting.
So, as someone else posted, if you use a "standard" screen reader, the label will be read. If you use a lesser known screen reader, then it's hard to say what will happen.
Regarding aria-description, that's not production yet. It's part of the ARIA 1.3 specs which is still in draft form. The production ARIA 1.2 does not have aria-description so it's doubtful it will be read.
ACcording to ARIA specification, the <section> can perfectly have the aria-label attribute.
Most other HTML5 structural elements also allow aria-label because they are landmark regions.
So, conforming screen readers are supposed to read it, and, as far as I have tested, they indeed do.
Attribute aria-description is more recent than aria-label, so you should prefer aria-label in order to maximize the chances to have it read.
IN order to make good and relevant tests, I suggest you to use a true screen reader really used by users, rather than a browser extension that nobody use in the real life.
You may try one or more of the following, depending on your target systems and possibilities: (Non exhaustive list)
NVDA, Jaws and Supernova under windows
VoiceOver under MacOS, iOS and iPadOS
Talkback and VoiceAssistant under Android
NVDA, VoiceOver and Talkback are totally free, and VoiceOver is even always available out of the box without the need to install anything. So you really have no reason to don't try them out.
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.
Sorry if this is a too naive question, but what exactly is a screen reader? How should I consider them when designing a web page (html document)?
Doing a google search doesn't help much... and wikipedia's entry is too general.
Is there anything I should be adding into my html markup to deal with screen readers in particular?
A screen reader is software that "reads" a document (in your case, a webpage) and outputs it in a way that people with visual disabilities (e.g. blindness) can easily consume.
A screen reader can only understand text (and some formatting). Here are things you can (and should) do to improve accessibility for blind or almost-blind people:
Use the <strong> and <em> tags rather than non-descriptive <b> or <i>. If it's being read aloud by the computer, it can put emphasis on those words.
Always include the alt attribute on images. You can even leave it blank (also known as null - alt=""); this signifies that the image is not essential/decorative. Otherwise, put a text description of the image.
The title attribute is generally ignored by accessibility software. In effect, only people that can use computer mouse can ever read it, so avoid it.
Turn of CSS and look at your page. If it doesn't make sense, you should reconsider the layout.
ARIA roles (via the role attribute) are helpful. For example, if you make a link look like a button, assistive technology provides different interactions. So by setting the role correctly, people using assistive technology can use that element as you intended. In that case you set role="button"
Use tags with semantic meaning (like section, article, nav, aside, header, as well as the more common h1...6 tags) rather than divs and spans that you style with CSS. This lets software make an outline of your page and a blind person can jump straight to the main content just like you can scan it with your eyes.
Related to the last one; make it a point to use lesser-known tags like time and abbr and address rather than yet another CSS class.
And that's just for screen readers. Not even considering deaf people -- look into captions for your videos and audio (with the new HTML5 <audio> and <video> tags).
Please be aware that I am not an expert on accessibility (and I'm not blind either, so I don't speak from experience). The W3C has standards on accessibility that are probably more advisable than mine (and a list of quick tips as well).
Screen readers are typically used to make the computers accessible to users with visual disabilities, e.g. If you are blind you won't be able to see a website but with software you can have it "read" to you.
The most common screen reader I know of is the JAWS screen reader.
JAWS is short forL J ob A ccess W ith S peech (hence the name) and is a common tool used when trying to ensure your website or Web application is accessible. E.g. Creating sites for the U.S. Government require ensuring your content is accessible according to the Section 508 of the Rehabilitation Act: http://www.section508.gov/
All of the info you might need is on that site but a few of the quick tips would be:
add informative descriptions to images with alt attributes
use <TH> tags to properly define table headers and use the scope attribute
ensure that your site/app still renders in a readable manner when the CSS is disabled
Your question is two folded:
A screen reader is a piece of software that reads the screen and converts that to something people with visual disabilities can consume, like audio or Braille. In terms of the web, it reads the DOM, versus the actual screen.
What you have to do can be quite simple: make your application easy to understand for screen readers. You do this for example by providing alt with an image. There is a standard for working with screen readers at the W3C called WCAG. What you really need to do primarily depends on your audience. If it is unlikely to have people with such disabilities on your site, you probably have to do none to less work for it.
When creating a website why should you care for HTML with no style?
Is there any device which will render HTML only (no CSS or JavaScript)?
Do you usually care how your website will display without CSS?
Why is it important?
There are several cases in which websites may be used without styling. As mentioned in the comments, screen readers (such as those used by visually-impaired people) read only content, not styling.
Perhaps more importantly, many search engine spiders (think: Google) read your site without styling. When you view your site without CSS, you will gain a better understanding of how search engines view your content.
And if you are lucky, or your content is particularly geeky, you may get the occasional guru who browses your site via Lynx.
There seem to be a few misconceptions here. First of all and most importantly, screenreaders do take into account CSS and JavaScript. Why? Simply because unlike in the past they are not running on their own, but rather work as addons for existing browsers or include the render engines inline in their own systems.
Does that mean you don't need to concern yourself with screenreaders at all? Sadly that's not the case either. For example, if you add display:table to an element just because you want to vertically align something some screenreaders will actually treat it like a real table (which makes no practical sense). The good part is though that pages are read top-to-bottom, header and menu first (if found) and that adding display:none through javascript to an element will hide the element from the screen reader as well. Now, the following is going to sound really harsh, but except if you're making a real high profile website I wouldn't advice you to concern yourself with this too much. On one hand screenreaders are becoming better and better (try for example the one that's included on your android device if you have a recent version of android) and on the other hand blind people are used to websites being a 'bit' messy. Now, that doesn't mean you should start using flash or otherwise crazy stuff, but it does mean that if you just write a proper website, make your menu a list, make your divisions divs and not tables etc. you should in general be fine. And if you are making a high profile website then you should check out WAI-ARIA.
Now, getting to the search engine part, that's not true either for the big search engines at least. Google does take styling into account. Not all the styling that's unimportant for Google, but it actually will realize which stuff is hidden and analyzes the javascript whether hidden content will be shown (as part of it's anti-SEO work), it will search for links in your javascript and probably lots more I am not aware of. Bing does this to a large extend as well, though for example duckduckgo does not do this too much/at all. Either way, once again, the notion that Google sees your site like lynx does was true in the far past, but by now is invalid.
And if you check your serverlogs you will see that nobody accessed your site through lynx. That's just the reality of life nowadays. In the past (again) people would occasionally use lynx if they only had access to a console, but nowadays it's far easier to pull your phone from your pocket which runs a full web browser.
First part of the answer : 'text based browsers'
Text-based browser list
Alynx
ELinks (active version of Links)
Emacs/W3
Line Mode Browser
Links
Lynx
Net-Tamer
w3m
WebbIE
Second part : 'search engines'
List of semantic search engines
List of search engines
Third part : 'web accessibility' where software helps people with disabilities get access to the web.
It's important to note that for the third part, accessibility, it is
sometimes a legal requirement. For example, in the UK it is illegal to
have a website that is not accessible to blind people. There are
similar requirements for US government services. – slebetman
It's also an applicable law in canada
See this list of tools from w3 for a Complete List of Web Accessibility Evaluation Tools
CSS isn’t an on/off thing. Although CSS may be completely disabled, it is much more common that some of your CSS settings get ignored or overridden. Here is an incomplete list of cases (see my CSS Caveats for some additional details):
Speech-based browsers generally ignore most of CSS, largely because most of CSS is directed towards visual rendering.
So do “text-only browsers” (more accurately, character cell browsers, which render in plain text only using a monospace font but may be able to use colors and bolding).
Search engines generally don’t care about CSS at all.
CSS support varies. The more advanced CSS features you use, the more probable it is that many browsers don’t implement them.
CSS support may be disabled by the user, completely or partially.
User style sheets may interfere with your CSS code or even override them.
Browser settings e.g. on minimum font size may make some of you CSS settings ineffective.
Browsers have bugs. The more complicated CSS techniques you use, the more probable it is that you trigger a bug in some browsers.
An external CSS file (the recommended way of using CSS) may get lost, e.g. a browser may need to wait (perhaps in vain) from a server, or an archiving system may archive an HTML file but fail to archive the CSS file.
Styling may get lost in transfer, e.g. when copying content from a web page to MS Word or Excel or Notepad or email.
I'm writing a blog post about the kbd element, and as part of that I'm trying to see if it actually helps in terms of accessibility, e.g. do any screen readers reckognise the kbd element or do anything with it?
I've tried googling around for an answer but turned up nothing (possibly attributed to how few people actually use this element?)
There does not seem to be any evidence of any particular handling of the kbd element in browsers, assistive software, or otherwise, except for the default rendering (which uses the browser’s default monospace).
It is difficult to image what any software could do with it, since it simply indicates that some text is presented as user input – it just represents it, without actually involving any user interaction. And the content can be just about anything. User input is often a command or a filename or other “computerish” expression, but it could equally well be in a natural language or a meaningless string (say, a password).
It would make sense if screen readers read the content marked up with kbd in a different tone/voice/speed/etc. (resp. announce it).
Otherwise it would not be (always/perfectly) clear what should be entered and what not.
Example where it would not be clear what exactly to type in:
<p><kbd>Say hi</kbd> to get an introduction.</p>
<!-- vs. -->
<p>Say <kbd>hi</kbd> to get an introduction.</p>
Example where it would not be clear that anything should be typed in at all:
<p>
<kbd>kill</kbd> to kill yourself, <kbd>kill <var>name</var></kbd> to kill the player named <var>name</var>
</p>
Example where it would not be clear if/which punctuation has to be entered and if keys have to be hold (+):
<p>To enable god mode, press <kbd>a+v!c</kbd>.</p>
<!-- vs. -->
<p>To enable god mode, press <kbd>a+v!c.</kbd></p>
<!-- vs. -->
<p>To enable god mode, press <kbd>a</kbd>+<kbd>v!c</kbd>.</p>
If any screen readers ship with kbd support enabled by default is another question, that probably can't be answered for sure, because there are many screen readers that are available only for one language resp. in one country (let alone all the different versions).
But I guess most advanced screen readers can be configured to "do anything" with kbd. I know that many screen reader users share snippets/configs on mailing lists to improve their experiences. I wouldn't be surprised if some also added some support for kbd.
Besides from accessibility for screen reader users, kbd can help other users, too, of course. I've often looked at the source to figure out what exactly should be entered when kbd didn't get any special styling.