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.
Related
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
On our site we have a case where we show a list of images that have been uploaded by various users of a product we sell. We don't have any context as to what the image is of other than the product we're selling on the page. Here's the various options we've discussed:
Empty alt tag alt="". Screen readers would read nothing.
Alt tag saying it was user uploaded alt="customer uploaded content". This would repeat the same thing for every image.
Same thing as (2) but instead giving an index for the image to show the number of them there are alt='${index} customer uploaded content'.
Omit the alt attribute entirely.
I am less concerned about SEO in this specific case than I am accessibility. I'm not sure what the best practice is and if having screen readers read out repetitive content could potentially be bad.
The specification has exhaustive information about the alt attribute including a section Images whose contents are not known:
In some unfortunate cases, there might be no alternative text available at all, […] because the page is being generated by a script using user-provided images where the user did not provide suitable or usable alternative text (e.g. photograph sharing sites) […]
In such cases, the alt attribute may be omitted, but one of the
following conditions must be met as well:
The img element is in a figure element that contains a figcaption element that contains content other than inter-element whitespace, and, ignoring the figcaption element and its descendants, the figure element has no flow content descendants other than inter-element whitespace and the img element.
The title attribute is present and has a non-empty value.
(snip)
A photo on a photo-sharing site, if the site received the image with no metadata other than the caption, could be marked up as follows:
<figure>
<img src="1100670787_6a7c664aef.jpg">
<figcaption>Bubbles traveled everywhere with us.</figcaption>
</figure>
It would be better, however, if a detailed description of the important parts of the image obtained from the user and included on the page.
I am less concerned about SEO in this specific case than I am accessibility. I'm not sure what the best practice is and if having screen readers read out repetitive content could potentially be bad.
Make it easy for screen reader users to skip the section. Make use of <section> elements and <h1> and friends. That way when they get the announcement "Section: Customer photos", they can skip to the next heading.
Best Practice: ATAG
The best practice would be to acknowledge that your site is an authoring tool, as it allows creating content, and to conform to the Authoring Tool Accessibility Guidelines (ATAG).
This would mean (among others) that you
Make it possible to provide an alternative text for users that upload photos to Ensure that accessible content production is possible
Assist authors with managing alternative content for non-text content
Provide an error or warning if alt is missing, to Assist authors in checking for accessibility problems
I'm a screen reader user myself, and I would vote for #1, or maybe #3, depending on the situation.
Your #4, no alt text, is in any case the worst one. Many screen readers render images without alt by giving the file name or even the full URL. It is always a totally useless annoyance.
Your #2, a generic alt text like "User uploaded content" is better, but if there are more than a few images in a row, less experienced users may think that they have reached the bottom of the page, or that the screen reader and/or the website are buggy.
For more advanced users, it's anyway no useful information.
Your #3, a generic alt text with indices like "Photo 1", "Photo 2", "Photo 3", "Photo 4", etc. is better than #2. Since the alt text differs by their indices, you can't think that you have reached the end of the page or that something is buggy.
It's still no useful information.
However, I think that the best of your solutions is #1, an empty alt text.
Since the images provide anyway no useful information, they are better entirely skipped. In practice, that's what we do everyday when such such images are present.
There is one case where I would recommand #3 instead of #1 though: if you can do some action by clicking on the images.
IN this case, the empty alt text would prevent a screen reader user from launching the action. Image links, buttons and other actionnable elements must always have a non-empty alt text.
Another case when #3 might be useful is if I'm myself the author of the content. IN that case I might want to check if my images have correctly been uploaded and inserted where I want them to appear.
IN all other cases, I would go for #1, for the reasons explained above.
Of course, the real best solution would be to allow users to give an alt text while they edit their content, and educate them about it.
You may argue that it's a description and that it would help them finding back their images; very useful if you give access to a place where they can see all what they have uploaded on the site in a single page, or if you allow them to upload images in advance.
I'd say to put it like this:
alt="Image of {product}, uploaded by {user}"
It says what product is in the image, and that is was uploaded by a user.
assuming that you are building an dynamic web-app you can attept the try of Tobias and insert dynamic content in the alt tag. otherwise i think you have to stick at solution 2) since you cant dynamize content in html.
In striving for WCAG 2.0 Compliance, I'm finding quite a bit of varied information regarding proper treatment of buttons, specifically what is required to consider the button accessible and compliant.
What is the appropriate way to mark-up a <button>? What attributes or combination do they need to have?
My buttons fall into three categories:
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
For instance, in the following simple example of 3 above: http://codepen.io/ga-joe/pen/ggeLeW
Is it acceptable to add only an aria-label attribute for a button with no text? Are name and / or value always required? Please send help! Thank you!
These seem to be the relevant WCAG Guidelines:
https://www.w3.org/TR/WCAG20/#text-equiv-all
https://www.w3.org/TR/WCAG20/#navigation-mechanisms-refs
https://www.w3.org/TR/WCAG20/#ensure-compat-rsv
These kinds of questions always depend on context. Let me give it a shot sans context.
<button>Learn More</button> does the trick as long as contextually someone will understand what they will learn more about. Usually the button is preceded by some descriptive text. However, if it just brings someone to another page as opposed to firing a modal, I would use a link.
<button aria-label="Close">×</button> for a close button (I am using the character entity for ×, which is more symmetrical than x. Again, if the button is at the top of a modal (for example), perhaps adjacent to its heading, then that is probably adequate.
<button aria-label="Image 1">[icon]</button> can work for a carousel. Note that a font icon can be lost if the typeface does not download. A background image will disappear in Windows High Contrast Mode (WHCM) for IE11 and older versions of Edge. The aria-label will not help the WHCM users. Probably best to use an image (even an SVG) and its alt attribute instead, which means then you do not need aria-label.
You do not need a name attribute. It does nothing useful here.
Do not use a role="button" attribute. That role is automagically part of the <button> element. If you assign another role, then you have a big problem.
Definitely do not use a title attribute. That does more harm than good.
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
You can read the recommendations for WCAG 2.4.9 Link Purpose (Link Only) even if we're not talking about links. The text "Learn more" can be understood when in context, but for low vision users who require screen magnifier, for instance, it can be difficult to understand the action from the button text itself.
For instance the text Learn more about "Wheels on the bus" may seem more appropriate.
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
I answered that subject in another post:
What is aria-label and how should I use it?
You have to use both aria-label (useful for screenreaders) and title attributes (for standard users using standard browsers which may need more support):
<button
aria-label="Back to the page"
title="Close" onclick="myDialog.close()">X</button>
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
The same reasoning can apply to this point. But for blind people, moving a carousel to the left or to the right is a different experience, sometimes useless. If they can ignore that what they see is a carousel, without losing any content, navigating with the keyboard or their assistive technology, then you are doing what is expected.
Also, you have to never forget that accessibility does not only target blind users, but also children, old people, people with cognitive or sensitive disabilities. For instance, the aria-label will never be sufficient enough to help those people when needed. They do not have a screen reader, and they do not read the HTML source code.
In the case of users using "speech-recognition software" (yep, they are not a lot but let's improve their life), not having any visible text can also lead to difficulties.
For a WCAG 2.0 compliant website need to have alt tags for the images.
When it comes to something like a company logo. Should the alt tag just be the name of the company, or the name of the company followed by "Logo" I think the former makes more sense but if there is a definitive best practice I would like to know!
Exciting question eh?
The best guideline is, if the image wasn't available - what would you want to see instead?
The alt text shouldn't be a description of the image, it's a textual alternative to the image.
Is the logo of value to users of screen-readers? If not--then consider displaying the image via CSS rather than an <img> tag--CSS (presentational) images do not need to have alt tags (they actually can't have them), they are understood to be a visual-portion of the page rather than the actual content of the page.
implies that the image is valuable content related to the page--so if the logo is essentially eye-candy, of presentational value only, then it may not belong in HTML at all.
Just remember: screen-readers allow users to access the content. HTML is for content, CSS for presentation--if your HTML is muddied with non-content then providing a good, accessible, experience becomes much more difficult.
I think it's up to your personal preference. You want to convey the meaning of the image, not exactly what it is. for example, i would use alt text like 'next page' instead of 'right arrow'. So I would go with the company title, as that's the point of the logo.
I would go for "Logo of (Companyname)" because the ALT text serves as a description of the image that gets served if the user can't see it (e.g. for screen readers).
I think the WCAG 2.0 guidelines are supporting this:
When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image.
Well, whatever makes the flow of the text of the page most understandably. IF the logo is right next to the company name as text, then neither "Big Company Big Company" nor "Big Company Logo Big Company" is really best when spoken by a screen reader.
The requirement for alt tags is mostly for images as buttons:
<img src="next.png" alt="next page" />
or other places where the image conveys real information, like graphs and charts.
Places where the image is merely decorative, a blank alt tag might be best.
Imaging an "About the company" web page, with all images with alt tags, being read aloud by a screen read. (Actaul text from exxonmobil.com: "About us- two workers on the Kizomba platform in Angola - We are the world's largest publicly traded international oil and gas company") Dragging the irrelevant detail from the image here lowers readability instead of raising it.
I wish I could point to an authoritative source, but having dealt with accessibility in a former life, I believe "logo" is preferred as it more accurately denotes the entity. For example alt="Photograph of Mount Hood" is quite different than alt="Mount Hood" and the former is much preferred.
While I do very much like #Gareth's answer, there is another thing to consider:
What is the parent element of the logo? If it is marked up like so: <img src="/company-logo.png" alt="" />, then the best alt would actually be along the lines of "[Company] Home Page" or "Go to [Company] home page". A disabled user with a screenreader would then hear "[Company] Home Page, link", or possibly, "[Company] Home Page, visited link".
Any time you are using an image as the link content, then the alt should tell the user where they go when that link is clicked. Same with buttons. If you use an image as button content, then the alt should tell the user what happens when the button is clicked.
Just as an aside: if clicking takes the user to another page or another part of the page, but requires no further interaction, the clicked element is almost always semantically a link. If clicking performs an action apart from navigation, shows additional options or content, or requires further interaction from the user after clicking (opens a dialog that must then be closed), then the clicked element is almost always semantically a button. Whenever possible, use the proper semantic element and style it with CSS. This will make your content accessible to the broadest range of assistive technologies.
How to write good alt text for images to help screen reader and blind user to understand what is picture about ? and if we are using Alt text then what should be in a Title="text" if we are using both in special cases like menu images etc
I'm a screen reader user and will use Stack Overflow as an example of both the good and bad.
Alt tags should be brief and descriptive. For example, Stack Overflow's alt tags for the vote up and vote down options are nice since they don't take long to read and get to the point quickly. Examples of bad alt tags are the make this question a favorite and accept this answer. Neither of the tags are descriptive, the favorite tag is just "*" and the accept the answer tag is "check" The only way for me to tell what they are is to read the source or have someone sighted let me know what they are for.
As far as title attributes go I don't really have much advice. My screen reader doesn't read them by default so I don't normally use them. An example of something that could be useful is additional information. For example the reason my accepted answer rate is so low is because I have no way of telling whether I have accepted an answer on a question. It would be nice if the title attribute on the accept this answer graphic would say something like "click to accept this answer" if the answer wasn't accepted and "Click to remove this answer as the accepted answer" if it is the accepted answer.
You should not make the visually impaired user understand what the image is all about. For the blind, the image effectively doesn't exist, all that there is is the text.
The alt text should work as a single sentence/paragraph that can be replaced for the image, convey the same content and still make sense in the context of the adjacent content.
If the image is something that is part of the GUI, then the alt text should convey an action (a verb), line upvote, answer this or log out.
You should visit your site with links and try to understand your site. If there is for example a pie chart, its alt text should be a small summary of the percentages. If you just have a pretty flower next to a blog post, don't give it an innane alt text like flower image companion of blogpost #324 or even worse flower.jpg.
If the image is important to the navigation or to get information, try to give it an alt text that makes the site work without the image. If the image is only presentational, give it an empty alt text.
title, as far as I know, should only displayed when hovered, so they should give extra information to the image, so useless duplication of information should be avoided. For screen readers, this is a bit trickier, as support and configuration can be very different between users.
Some empirical data shows title as useless:
Most users of screen reading software do not change their default settings to access the TITLE attribute information on links.
Most screen reading software can access TITLE attribute content on form controls by default.
Some screen reading software cannot access TITLE attribute information.
Users of screen magnifiers can read TITLE attribute text at lower magnification levels.
Users of screen magnifiers cannot read TITLE attribute text, that contains more than 1 or 2 words, at higher magnification levels.
Here's good piece of advice, better put than I could
Use this to provide additional information that is not essential. Most visual browsers display title text as a tool tip when the element is hovered over, however it is up to the browser manufacturer to decide how the title text is rendered. Some will display the text in the status bar instead. Early versions of Safari did this, for instance.
One good use of the title attribute is to add descriptive text to links, especially if the link text itself doesn’t clearly describe the link’s destination. This way you can help visitors know where the link will take them, possible saving them from loading a page only to find out it wasn’t anything they’re interested in. Another potential use is to provide additional information for an image, like maybe a date or other information that is likely not essential.
Remember that the longdesc attribute is supposed to be a link to further information, not text as some people missuse it.
I think the best practise is to put same content in alt and title attributes.
Regarding 'what to write' - just simple, in few words what is on the picture.
Check this article where alt attributes are described pretty well: http://www.cs.tut.fi/~jkorpela/html/alt.html