For the HTML title attribute, Mozilla's docs mention...
Use of the title attribute is highly problematic for:
People using touch-only devices
People navigating with keyboards
People navigating with assistive technology such as screen readers or magnifiers
People experiencing fine motor control impairment
People with cognitive concerns
This gives me a seed of doubt whether I can innocuously use title all over the place.
Would the mere existence of title actually introduce problems for certain users?
Or put another way, is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?
I'm just trying to maximize my UX & accessibility optimizations to 110%.
I can conceive of three different problems that using title attributes can introduce for those various groups.
No access
Some users don't use technology that would display the title attribute. This isn't a problem is the title attribute contains information that isn't required to understand the content.
Physically getting in the way
A tooltip might cover up some other information when it is rendered. You can probably compensate for this with space. Don't cram everything together. Allow enough room on a hover target so a tooltip can render in empty space, or at least space that doesn't contain information about the element being hovered.
Interruptions
If you scatter titles in the middle of a sentence, then I expect some screen readers will interrupt the sentence to read the tooltip. This won't make it easy to understand the document if it happens a lot.
I wouldn't go overboard with them.
(Related, but less of an accessibility issue, if the titles duplicate information in the text, then it is going to be very repetitive and annoying).
That depends, as always. Usage of the title attribute is not harmful, but relying on it is.
To quote the HTML standard:
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute
Mostly, title is used to implement the tooltip pattern, which is then not very accessible, as stated.
So if you provide that supplemental information by accessible means as well, the title attribute does most likely not harm.
“[…] is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?”
Well, the WCAG accept title attributes as a sufficient technique to explain abbreviations in an <abbr> element or to label form controls, even though actual technical support is not great.
To name <iframe> elements it is still the only documented sufficient technique
If you use it on <style> and <link> elements, it allows the browser to provide a style switcher.
<link rel="stylesheet" href="dark.css" title="Dark Theme">
See also The Trials and Tribulations of the Title Attribute
Related
Is the following HTML accessible?
<a id="myClickbaitArticlePreview" href="someUrl">
<h3>Amazing lifehack! Doctors hate him!</h3>
<img alt="doctor is staring down a patient" src="procativeThumbnail">
<p>Compelling copy</p>
</a>
I know it's valid based on this answer. But is it accessible? Cause I am auditing a website with a similar article structure using a screen reader (JAWS). The reader reads everything in a single breath which is confusing (but I am not blind so I don't know if you get used to it). It also reads the alt right after the title, which in many cases may repeat the content.
Short Answer
It is both valid and "accessible" in the loosest sense of the term, a good experience for screen reader users - probably not.
It would pass all WCAG guidance, let's put it that way.
Longer Answer
Without seeing it in the context of the page though it is hard to tell you whether this is the best practice. A few things to consider:-
Is there sufficient white space around these large "link cards" for people with mobility / accuracy / dexterity issues to safely place their finger to scroll the page on a mobile device.
If the link card is focused is the focus indicator easy to see and sufficient contrast etc. (standard thing to check for but often forgotten on card type links)
If a screen reader user cycles the page via headings is it logical to have a <h3> in the card, both in terms of heading hierarchy and in terms of page hierarchy.
Are the alt descriptions correct in their context, if the image is not directly related they may be better being hidden from screen reader users with aria-hidden or an empty (not null) alt attribute (alt="" NOT alt). I would almost certainly say this will be the case but yet again that is your judgement.
alt being the same as the <h3> title - this is almost certainly a big no no. alt attributes should describe the image in context. If the alt text is the same as the title then make the image presentational / hidden from screen readers as discussed in the previous point.
Should these be <article> elements to be semantically correct?
Are they contained in an <ul> so that a screen reader user knows how many items there are?
would an aria-label on the hyperlink with a condensed version of the text be appropriate (to override the text inside the hyperlink)? It depends on the content so use best judgement.
Would a hyperlink styled to look like a button at the end of each article be better? If so make sure it doesn't just say "read more" (although at a push you could have "read more" as the button text and have some visually hidden text that says "Amazing lifehack! Doctors hate him!" before it).
As you can tell, without seeing them in context there is lot's of things we cannot tell you but hopefully the above should give you a few things to think about.
As for the screen reader reading everything in a single breath, that is expected behaviour, you just need to get used to it! You could always slow the speech rate in the settings or increase the announcer verbosity (so it has more detail about what element you are in relative to other elements) while you get used to it.
According to HTML standards, the a element has a transparent content model with the sole exception that it can't contain interactive elements.
An heading is not an interactive element. So that's good according to the standards.
Regarding accessibility the text link is not optimized.
WCAG in 2.4.4: Link Purpose (In Context) expect a "meaningful link". Having too much information is not a good practice. A better alternative would be to provide a javascript click handler on a <div> while only having the HTML link element on the h3 here.
In your example "doctor is staring down a patient" does not describe the link destination and should not be part of the link text alternative.
Can someone advise me if there is a specific WCAG 2.1 failure when buttons are used as links. Same question vice versa. Links as buttons.
I have a site i am working on where by design there are links that appear the same as the buttons do.
So you may have buttons <button> like:
Edit details - which takes you to a new page where you can edit items in the page where the "edit details resides".
Continue - a button that takes you to the next page in a series of pages.
But then have links <a> which appear as buttons, so the same style, but they are labelled select, select and selected and these are a product type, so do not link anywhere.
Another example is the back link is a button<button> but looks like a link (text with underlined style)!
I know that this behavior confuses voice recognition as the user says click link or click buttonand not all objects get flagged that appear the same.
My question is does this fail WCAG2.1 specifically? Would this fall under 4.1.2 Name, Role, Value?
The 4.1.2: Name, Role, Value undestanding addresses the case of elements having different role than usual.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
As Adam already cited, "additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies". So yes, this fails WCAG 2.1, unless you take measures to ensure that your button-links and link-buttons really work as they are supposed to for example that a <a role="button" […] can be triggered using the Space key.
If you really have accessibility in mind, don't mix <button> and <a> elements up. Not even if you think you are smart and add role="button" to a link or role="link to a button. You would have to do more than that to make them behave like each other (see MDN about the button role).
And even then you should consider this: links are for navigation, buttons for performing actions. If you have a navigational element that looks like a button, its behavior might be confusing (even if it has no role="button" attribute). Also note that the default value for a button's type attribute is submit ("The missing value default and invalid value default are the Submit Button state.").
Web accessibility should encompass all disabilities that affect access to the Web and there are a lot of possible disabilities – and having one disability does not necessarily mean a person has no other disabilities.
The easiest step of making your website more accessible is to stick to the standards. Don't change an element's behavior unless you really have to (and even then: do you really have to?).
Update: General comment about WCAG and accessibility:
Web accessibility is also not just about simply conforming to guidelines like the WCAG. Even the WCAG itself does not claim that a website will be 100% accessible when conforming to it:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.
Update: Examples of possible violations of WCAG 2.1 (with room for interpretation though)
Just letting links look like buttons and nothing could be failing:
Guideline 3.2 Predictable in general ("Make Web pages appear and operate in predictable ways.")
Success Criterion 3.2.4 Consistent Identification (unless all links look like buttons; the only actual success criterion in these examples)
4. Robust in general ("Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies." & Guideline 4.1 Compatible "Maximize compatibility with current and future user agents, including assistive technologies." --> you already mentioned voice recognition and the possibility of not being able to target a link because it looks like a button)
Jonathan Pool wrote a blog article about this issue in which he points out another possible violation:
Worst case: A button that takes an irreversible action ("Yes, I confirm that I am waiving my rights.") pretends to be a link, so the user tries to use SPACE or SHIFT-SPACE to scroll the page but unexpectedly presses the button. This, arguably, would violate Web Content Accessibility Guidelines 2.1 Success Criterion 3.3.4.
HTML5 introduced many semantic elements (<nav>, <section>, <article>, etc.). But aside from helping read and structure our HTML, do they have any other unique properties? Or are they essentially just <div>s with different names? It seems like the latter is true.
I keep reading about the "semantics" but can't find a direct answer.
The <nav>, <section>, <article>, etc., elements don’t have any special properties that are exposed to frontend JavaScript code; instead they all just use the HTMLElement interface.
However, they do have special properties in screen readers—in that they get announced to screen-reader users in a special way that a div element doesn’t.
Screen readers can announce that a certain part of a document is a section or article, and allow screen-reader users to navigate through the document section-by-section, or to more easily jump among articles.
That said, screen readers also enable users to easily navigate through a document by jumping among its h1-h6 headings—regardless of whether those headings are in section or article elements—so for screen-reader users it’s actually more important that your documents have good informative h1-h6 headings and a logical structure.
Semantic elements are elements that describe the content. They provide more information to the browser without requiring any extra attributes.
Considering Microformats
When you’re adding semantics into your web pages, you should consider using microformats to add even more meaning, when appropriate. Microformats use human-readable text inside the HTML (usually in the class attribute of an element) to define the contents.
Microformats add semantic information about the elements, and this information is already being used in certain situations.
Above figure shows a Google search for reviews of the movie Ender’s Game. The second and third results show “rich snippets,” including information like the star rating.
Google and Bing are both using these types of rich snippets to enhance their search results, and most of the data they are using to get it is semantically marked-up HTML using microformats. You can learn more about how to use microformats in my book Sams Teach Yourself HTML5 Mobile Application Development in 24 Hours.
By writing semantic HTML, you give more information to user agents to use to display the information correctly. For example, if a screen reader sees the element, it knows that this is the main point of the page, and it will read it aloud before reading anything in an element. Plus, as web pages get more and more sophisticated, what the user agents do with them gains sophistication. For instance, in the future, your semantically marked-up recipe could tell a web-ready refrigerator what time to alert the robot butler to start the roast.
I've a case where I'd like to use aria-label to give screen-readers access to the (CSS pseudo-)content. Something like this:
[data-pseudo-content]::before {
content: attr(data-pseudo-content);
}
<h1 aria-label="This is the title" data-pseudo-content="This is the title"></h1>
Is it bad to use aria-label for content rather than a label for the content? Also, would some screen-readers read This is the title twice?
To the best of my understanding, aria-label can be applied in some situations to change or enrich the accessible name of an element (= the textual representation that will be outputted to the user, either by speech or by braille).
The amount of influence of aria-label or aria-labelledBy on the accessible name depends on how much information the node contains and its type or role itself.
Your example (confirmed with NVDA on Windows 8.1 in Chrome 42 and Firefox 36) doesn't make much of a difference for a screen reader, as it will follow a set of rules to determine the accessible name. In my experience, a screen reader will - among others - give priority to the containing text if other conditions (role) fail. If the node would happen to be empty and other alternatives are not available, a screen reader will render aria-labelledBy or aria-describedBy as the accessible name if provided. Otherwise it will be ignored.
Luckily in your case, the ARIA standard also covers :before and :after as part as the algorithm for determining the accessible name. You can read more about how the accessible name is being computed at the spec: http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
When would aria-label or aria-labelledBy make a good use? I'm still researching the subject, so I cannot provide a 100% certain answer for the time being. I do, however know that it makes a difference on elements like <input>. You should apply aria-label when there is no visible label available. It might also be useful to know that, whenever aria-labelledBy is rendered, it will always be placed first in the accessible name. This could be useful for form fields, because <label> might not always be rendered first if many attributes are given. aria-label / aria-labelledBy are also useful when you use the contenteditable attribute on an element, to make sure that the content is accessible for screen readers.
Here is a wiki with some examples of how aria-label / aria-labelledBy could be applied (search on page for those words): http://www.w3.org/WAI/GL/wiki/Category:ARIA_Techniques
Remember: the best way to figure out what works and what doesn't, is by playing around with a screenreader. I have not been able to test with other screen readers (apart from NVDA and iOs VoiceOver for a while), so the implementation on other screen readers like JAWS might differ. Other known screen readers are Windows Eyes and Supernova (though I heard that SN is not good with replacing focus with .focus(), so be careful). It might also be a good idea to test in different browsers, as the accessibility API might differ and give slightly different outputs.
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.