I'm having an accessibility problem with the button element. I'm wondering if this is the good way to do it. I have a button and the only content is a Font-Awesome (font-icon) in it. I was wondering if adding a title attribute to my button was enough to make it accessible ?
Like this:
<button class="prev" title="My accessible title">
<i class="fa fa-chevron-circle-left"></i>
</button>
The correct property in this case should be aria-label or aria-labeledby:
<button class="prev" aria-label="My accessible title">
<i class="fa fa-chevron-circle-left"></i>
</button>
With this, the screen reader for example will reproduce My accessible title instead the icon inside it.
See more:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute
You have to use both titleand aria-label attributes as some screenreaders does not read the title attribute, while other users won't benefit of the aria-label attribute.
You have to remember that accessibility does not only target screenreaders users but also every other people, so aria-label won't be sufficient.
Also note that, for better accessibility, you might want to add a way to show the description when you focus the button with the keyboard. That would be a good idea.
That being said, I will be silly enough to suggest that some part of the description of your button might be always visible for better accessibility.
For instance, the following examples shows how the two attributes might be used conjointly with a short visible hint for a popup close button :
<button aria-label="Back to the page" title="Close popup">
<i class="fa fa-times"></i>
Close
</button>
The title attribute is the most widely supported attribute for assistive technologies. This includes Dragon (which heavily relies on the title attribute for targeting elements) as well as all modern screen readers that implement the ARIA accessible name computation algorithm and many older screen readers.
As can be seen in step D of that algorithm, the final element that is evaluated is the title attribute.
Related
What is better for empty buttons (without text) in HTML, attribute "aria-label" or "button"?
I use this empty tags and buttons for nodes in JS.
Has there been some discussion that it would be better for accessibility?
For empty buttons in HTML, it is best to use the air-label attribute.
This allows screen readers and accessibility devices to provide a description of the button for users with visual impairments. "aria-label" (<button id="siteSearch" aria-label="Find in this site">Go</button>)provides a textual description of the button, whereas using the button tag without text can cause confusion for users with disabilities.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role#basic_buttons
Please note, as pointed out in other posts (Button with icon labelled with aria-label still an 'Empty Button' error) it is recommended not to put anything in a blank button but to leave the "standard view" like this:
<button type="button" class="btn btn-default dropdown-toggle">
<i class="fa fa-arrows">Sort</i>
</button>
I have a button which opens a calendar modal, I know calendars are bad for accessibility but my client insists on it. This is the code that opens that calendar modal.
<div class="col-sm-6 hidden-xs text-right calendar-cta">
<a type="button" onclick="openNav()" href="#" class="btn-primary">Calendar view</a>
</div>
I then have a close button on the model, which is where the accessibility error is being produced. The x is showing up as 'Text not included in an ARIA landmark'. What am I doing wrong? What do I need to add in order for this to stop producing the accessibility error. Any help would be hugely appreciated.
<div id="myNav" class="overlay" role="menu">
<a class="closebtn" tabindex="-1" role="menuitem" aria-label="close calendar view">×</a>
<div class="overlay-content"> </div>
</div>
This is more of a warning than an error. It's not required under WCAG, although it is best-practice, and you should try to do it if you can.
It is a best practice to include ALL content on the page in landmarks, so that screen reader users who rely on them to navigate from section to section do not lose track of content.
https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11
You should ideally be using HTML semantic sectioning elements, like: <main>, <nav>, <aside>, <header>, <footer>, etc. This warning is saying that all rendered content should be in some sort of containing element that has an ARIA role associated with it.
There's a great chart that maps all of the HTML 5 semantic elements to their implied ARIA roles.
I'd also recommend changing your a.closebtn to a button element and removing tabindex="-1". Since you're not navigating to a different location, but rather doing something that causes a change to the UI, I think that a button is a more appropriate choice. The tabindex attribute isn't necessary and only serves to prevent receiving focus by manually tabbing.
The direct and the short answers to the questions:
What is wrong here is that aria-label does not contain the visible text and it is a concrete WCAG failure under 2.5.3 Label in Name. Why and how it fails is explained under Failure due to the accessible name not containing the visible label text
Two quick and dirty solutions:
Write "close calendar view" instead of "x" if possible and remove the aria-label attribute
Hide the "x" sign from ARIA by putting it inside <span aria-hidden="true">x</a>. The one and only thing the screen reader will read will be "link close calendar view".
The "Text not included in an ARIA landmark" may still show up, it is a false positive when it is hidden from ARIA.
However, the above fix will fix only 2.5.3, but there are more important issues here.
I wonder
Why the role="button" was assigned to an anchor element to make a button, when there is the button element readily available and no link to anywhere was intended.
From Bootstrap:
When using button classes on elements that are used to trigger
in-page functionality (like collapsing content), rather than linking
to new pages or sections within the current page, these links should
be given a role="button" to appropriately convey their purpose to
assistive technologies such as screen readers.
What tabindex="-1" does there. It will remove the button from the tab order and the keyboard user will not be able to reach or operate it. It causes a concrete 2.1.1 Keyboard failure.
Why closing the calendar view button has a role="menuitem". Is there a menu there?
Moreover, the usage of the "x" character as the only visible accessible name of a button is a 1.3.3 Sensory Characteristics failure. It is an assumption that all users know "x" denotes "close". Just like not everyone understands an asterisk denotes "required fields", ">" sign means "next", or 3 bars on top of each other is now a menu called "hamburger menu". These should all have some textual explanation. Aria label makes the explanation for the screen reader users but some sighted users may still fail to understand what is meant there.
Alternative code, not including how the btn-close works: (Close button Bootstrap v. 5.0)
(Please note that Bootstrap does not address the 1.3.3 criterion explained above, that is why I included a tooltip in my suggestion.)
<div class="col-sm-6 hidden-xs text-right calendar-cta">
<button type="button" class="btn-primary" onclick="openNav()">Calendar view</button>
</div>
<div id="myNav" class="overlay">
<button type="button" class="btn-close" aria-label="Close calendar view" title="Close"></button>
<div class="overlay-content"> </div>
</div>
I need to use a font awesome icon inside an anchor element. The anchor element does not contain anything rather than the icon.
Ex:
<a href="#" aria-label="List">
<i className="fa fa-list-ul"
title="List View"
aria-hidden="true"
title="List View">
</i>
</a>
What I want to know is is it wrong to put aria-hidden="true" to the icon since there is no other text or content inside the anchor tag(In this case tag becomes informational so I think it is ok to use aria-hidden="false" here).
Is there any rules related to this so we all can follow ?
You have two things to consider:
people not using assistive technologies (=not relying on ARIA)
What alternative text will have people not using assistive technologies? A title attribute should be added to the a[href] tag.
This will help for instance, people with cognitive deficience, people with low vision, people with bad computer knowledge to understand the meaning of the icon. If you can show the tooltip on keyboard focus, it would also be nice.
people using assistive technologies
The Fourth rule of ARIA says:
Do not use role="presentation" or aria-hidden="true" on a visible focusable element
Perfect here, only the a[href] is focusable. This does not prevent you from adding the aria-hidden attribute on the i element as long as you keep an aria-label for valid alternative for assistive technologies.
How can I add accessibility to this
Text:
Buttons and Images and anchors:
<div class="btn-group" role="group">
<button class="btn btn-default">
<img class="profile-img">
<span id="user-name">john</span>
</button>
<button class="btn btn-default">
Log out
<i class="fa fa-sign-out fa-lg"></i>
</button>
</div>
<div>
Change recipient
</div>
Too little information provided. Context needed. That being said:
Add an alt attribute to the <img>,
make sure the link has a valid href,
don't rely on FontAwesome icons to convey critical information,
maybe dump the role attribute as it may not be needed (context necessary to know if needed).
Only you are suited to properly add semantics to your code and content, so we really can't do this for you. But, here are some important things to remember/do/follow:
Your HTML is not event valid, so start by correcting that.
Don't ever use an HTML element because of the way it makes the
visible page look (i.e. using a heading like <h4> to make text
small and bold). CSS should be used for all layout and presentation.
Use the most appropriate HTML elements to convey the semantics of the content you have. For
example, go ahead and use the <table> element if you actually are
trying to display tabular data and use <ul> and <li> to make menus.
Despite the (many) myths, the HTML5 sectioning elements (section,
article, nav, aside) are not recognized by most screen readers. Their use actually makes creating a valid document outline much more difficult.
The proper use of heading (<h1>...<h6>) elements is the best
thing you can do to convey a proper document structure.
Use WAI-ARIA landmark roles where applicable as that has been a
standard for many years and all the major screen readers understand
it.
For images, provide the alt attribute to the <img> tag, which is a description of the image. For example, <img class="profile-img" alt="profile picture">.
For semantics, use <em> instead of <i> and <strong> instead of <b>.
Also, look into ARIA (Accessible Rich Internet Applications). A useful ARIA attribute is the role attribute. It provides extra content about the element's purpose and functionality.
I've been reading about using ARIA to get screen readers to read labels that otherwise wouldn't be there. However, I'm having a hard time getting a dropdown menu (from Foundation 6) to be read. Consider this piece of code:
<li role="menuitem">
<label id="label1" class="sr-only">Testing click label</label>
<a class="submenu-link" href="/" tabindex="1">
<span class="has-tip right" data-tooltip aria-haspopup="true" data-disable-hover="false" title="Foundation tooltip">
<i class="fa fa-plus-circle"></i>
<span class="text" aria-hidden="true" aria-labelledby="label1">Click here</span>
</span>
</a>
</li>
There are two things I'm baffled about:
Why isn't the <a> tag being read by the screen reader like all others that aren't in a menu dropdown?
Why isn't the aria-labelledby being read?
I suspect it's the "aria-hidden" on the span. As far as the screenreader can tell, that link has nothing in it.
Also:
label might seem like a logical thing here, but it's actually only intended for use with inputs.
Putting aria-hidden and aria-labelledby on the same element doesn't really make sense.
Avoid tabindex=1; use 0 if you need it to be clickable/focusable by the user, or -1 if you just need to be able to focus it via javascript.
There's a lot going on in your code sample; can you explain or show what it is you're trying to achieve? Why is there a dropdown item with a label, with a tooltip with an icon in it? How is this menu item supposed to look and function? What do each of these labels actually represent?
Adding labels where appropriate is definitely good to think about, but wherever possible, let normal markup do the heavy lifting.