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.
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.
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>
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.
I am improving the accessibility of my site and my screen reader (currently testing with JAWS 15) is providing default instructions for an HTML element for which I want to provide different instructions.
So far, I've been able to add aria-label="In order to foo, you need to bar" but before moving off the element, the screen reader is playing the default instructions, which are incorrect (i.e. "Press X key to do Y").
Any advice on preventing default markup element instructions from being read by screen readers?
If I understood your question correctly, what you're referring to is called a tutor message. For example, "Press Spacebar to activate this button".
You cannot change nor override those messages because they are a part of the screen reader itself. They are, however, most used by the beginners, and as a user gets acquainted with his/her screen reader and Windows in general, he/she will tend to turn these messages off.
For instructional text that is associated with a form element, you might want to use aria-label or aria-labelledby for the actually form field label and aria-describedby for instructional text.
WAI-ARIA 1.0 Authoring Practices provide a good description of what the appropriate uses are for aria-label, aria-labelledby and aria-describedby. [http://www.w3.org/WAI/PF/aria-practices/#relations_labeling]