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>
Related
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>
Here's the HTML:
<div class="dropdown">
<button class="btn dropdown-toggle" type="button" id="dropdownMenuButton" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"><input type="checkbox" checked="checked" onclick="return false"/></button>
<div class="dropdown-menu" aria-labelledby="dropdownMenuButton">
<a class="dropdown-item" href="#"><input type="checkbox" onclick="return false" disabled="disabled"/></a>
<a class="dropdown-item" href="#"><input type="checkbox" onclick="return false"/></a>
<a class="dropdown-item" href="#"><input type="checkbox" checked onclick="return false"/></a>
</div>
</div>
Basically it's a Bootstrap dropdown example.
I need this to a table column filter, to be able to filter either by true, false, or no filter.
Never mind the JS logic here.
the checkboxes are "presentation only" - they should not function as checkboxes, they serve as checkbox symbols. I don't have time and resources to provide vector graphics / specialized fonts here. I want that as simple as possible. Paste that into JSFiddle and include Bootstrap to see how it looks.
all checkboxes must be displayed correctly on modern desktop and mobile browsers
It should not break anything.
The Visual Studio however warns me about input inside a button. I know, it's against HTML standard, but I tested it on Edge, Chrome and FireFox and it works. Is there a catch here?
I know, a checkbox (or any other input) BEHAVIOR inside a button element is undefined. But if I don't want them to function, just display - it should be OK? Well, I even taken care about the undefined behavior: if one browser decided to allow checkbox to function inside the button, I explicitly set onclick attribute to just return false.
So, would you leave it or not? Is there a better way to present such filter? Maybe a free web-font playing nice with Bootstrap? A web-font having symbols like checked box, unchecked box, star or any other symbol representing "I don't care if checked".
No, you shouldn't ignore the warning. It's invalid HTML to place interactive elements (such as <input> elements) inside of <a> links or <button> elements, and creates accessibility issues.
Some additional considerations:
Are your dropdown menu items acting like checkboxes? If a user clicks one, does the state of the checkbox change? If so, you should use <input type="checkbox"> elements instead of links.
Conversely, if your dropdown menu items are acting like links (taking the user to new content), you shouldn't make them visually look like checkboxes.
If you do find a semantically justifiable reason for needing <a> links or <button> elements that look like checkboxes, you should use an <img> for the box part of the checkbox instead of co-opting another element that isn't semantically appropriate.
The html structure looks like this
<div>
<a href="#"> some info
<div role="button" tabindex ="0"
aria-label = "close"
/>
</a>
</div>
When using screen reader the a tag get read "some info close" and then on focus on button it again read "close". All I want a tag to read is "some info" and button to read "close". What change should I make? I cannot change the HTML structure.
jsfiddle https://jsfiddle.net/5c1oywzg/1/
You can't have a focusable element inside another focusable element.
What change should I make? I cannot change the HTML structure.
Being given an HTML code, it's difficult to make a change without changing the code.
you're using a a[href] link for what seems to be a button
you have to separate the focusable elements
If you could have changed the HTML structure, this would be a better code:
<div>
<button> some info</button>
<button aria-label="close" />
</div>
Unfortunately, we can't change anything if you can't change the HTML structure as your structure is by nature malformed.
We can still use some hacks (using javascript for instance) like adding role=description and tabindex=-1 to the a[href] element and replace "some info" with an html button, but that would be against the second rule of ARIA :
Do not change native semantics, unless you really have to.
1.) The fiddle is different from the code you posted above. For my answer I used the fiddle code (and added a missing " for the href attribute...)
2.) The button is part of the link, so its content is read as part of the link. Do you really want the (same) link to work both when the button is clicked AND when "some info" is clicked. Looks like "some info" is supposed to be a label/comment for the link?
depending on what you want, I would either close the a tag before the button or only wrap the button into the a tag, labeling it wth the full text and hiding the text before that with aria-hidden = "true":
<div>
<a href="#">
some info
</a>
<button aria-label = "close">close</button>
</div>
OR
<div>
<span aria-hidden="true">some info</span>
<a href="#">
<button aria-label = "some info, close">close</button>
</a>
</div>
If you can only add attributes and not change the HTML structure at all you could do this:
<div>
<a href="#" tabindex="-1">
<div tabindex="0">some info</div>
<button>
close
</button>
</a>
</div>
Setting tabindex to -1 removes an element from the tab order while setting it to 0 adds an item. Generally on other values should be used. More info here.
Removing the a tag from the tab order and adding the div in instead will make the keyboard skip over the a tag and focus on both the div and button tags separately.
🎻 Fiddle
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'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.