If you have a link nested in a label element, clicking the link does not update state of the associated checkbox. Tested in recent Firefox and Chrome. This used to work 100% – I personally used this approach long time ago; also there are numerous topics on how to prevent the old behavior from happening.
I think that this has something related to GDPR maybe. A lot of cases where you put a checkbox agreement and a link to T&C for example, clicking on the link to open the T&C doc was checking the checkbox, while you may not agree with the conditions.
I have searched for any information when/why this was introduced as well as for potential workarounds, but I was not able to find anything.
<label>
<input type="checkbox" />
<!-- click here will toggle the checkbox -->
I agree with
<a href="terms">
<!-- however, click here will NOT toggle the checkbox -->
Terms & Conditions
</a>
</label>
This used to work before. As I said, most probably this was adopted by most vendors in order to patch the undesired effect of opening T&C for reading and "agreeing" at the same time with them. Unfortunately I was unable to find any proof for that.
Anyone having some info? Any workaround in plain HTML (no JS)?
Had the same issue and have found out that you couldn't solve it correct because of links are made only for navigation but not for checkboxing. Browser wants go throw the link first instead filling checkbox. You can write the link outside you checking area.
Related
I was working with the ability to paste images into a div where it would then be uploaded via a post request. So far it seems to be working, but I noticed this toolbar that seems to show up when I make the content editable. As a result of this, the user is able to manipulate the div beyond just pasting an image which is what I do not want them to do.
<div tabindex="1" id="pasteZone" contenteditable="true" onkeypress="return false">
<span id="pasteMessage">Right click and paste an image, or click and press (ctrl+v for windows or ⌘+V for Mac)</span>
</div>
I need the paste zone to be editable so that the windows context menu allows for the option to paste the screenshot and have the option to ctrl+v or what have you. But I also do not want my users to be able to add text. It seems that I am able to do that successfully as far as key presses go, but the toolbar destroys that possibility.
What I have done:
I looked online to see if other examples of this occurred but I could not find anything on this particular issue. I checked to see if this was the standard for any contenteditable enabled div, but it is not. Other websites that have this do not show this toolbar.This leads me to believe that this has something to do with Bootstrap. If this is the case, how would I prevent this toolbar from showing?
Image:
I'm working on a client project which acts as a resource and support system for vulnerable people. Accessibility compliance has been touted as the absolute highest priority for this site because of the expected users, so we're currently working to meet WCAG 2.0 Level AA as closely as possible.
Currently the code for the login/registration links in the header looks like this:
<div class="profile-summary">
<a class="profile-summary__link" href="/login">Login</a>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
Another developer who is working on the user management system wants to change the login link to be a form containing a submit button. Something (hypothetically) like this:
<div class="profile-summary">
<form action="/login" method="get">
<button type="submit">Login</button>
</form>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
This doesn't really sit well with me and it seems like something screenreaders and other assistive software will trip over (e.g. won't read the login option when summarising the page). To my knowledge some of these switch into a 'form mode' when they encounter a form, which would be jarring in this situation.
Are there any detrimental accessibility implications to using a form and button over a plain link in this context?
Thanks!
In this context, the link with href="#" is right out.
Adding a form can be more confusing than anything because it implies a different thing will happen between each of two otherwise similar controls. A form with no fields and only a button is even more confusing to many SR users. That may be a bigger problem than the links.
Remember that not all screen reader users are blind, so if these controls look the same but behave differently that is also an issue.
Without seeing what these two controls do, it is hard to offer specific advice about which element is the right choice.
Here is generally the way I approach this question...
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an <input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This had better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead. I tend to prefer <input type="submit"> as I find it runs into fewer conflicts (both mentally and stylistically) with developers.
Keyboard User Consideration
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I have a CodePen demo that shows this in action: http://s.codepen.io/aardrian/debug/PZQJyd
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
For reference: http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html
I manage several websites that use a featured article scroller on their homepages, which allows the user to click a forward or back arrow in order to see the next article headline and blurb while remaining on the same page.
I use WAVE's accessibility checker and any sites that have this particular plugin throw an error back because within the code there is an empty link, written as <a href="#">. Is there any way around this? I've defined a title attribute but the # is causing the empty link error to still come up.
Some places I've seen that this is perfectly acceptable and others claim this is a problem. What's the actual answer and potential workaround?
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
Some source suggests that link would be an invalid hypertext reference, but in fact the problem would exist only in non javascript browsers which is out of the scope of WCAG 2. This is not your problem here as this is not an error that WAVE considers.
The problem here is the fact that you have an empty link content and that adding a title attribute does not satisfy WAVE algorithm.
If your only concern is to satisfy WAVE, just put some content in the link and use any CSS trick to hide this content.
I currently have a form like so:
<form action="#">
<select {if $isPostRequest}disabled="disabled" {/if}size="1" name="locale"
onchange="location.href={if $languageToggleNoUser}'{$currentUrl|escape}{if strstr($currentUrl, '?')}&{else}?{/if}setLocale='+this.options[this.selectedIndex].value{else}('{url|escape:"javascript" page="user" op="setLocale" path="NEW_LOCALE" source=$smarty.server.REQUEST_URI}'.replace('NEW_LOCALE', this.options[this.selectedIndex].value)){/if}" class="selectMenu">{html_options options=$languageToggleLocales selected=$currentLocale}</select>
</form>
It currently causes a WCAG 2.0 error, as all forms need a submit button.
I'm wondering how I could change this code to include a submit button. The code for the onchange option is quite convoluted, and I don't understand it.
Thanks.
WCAG 2.0 does not require to have a submit button. What you link to is a technique, which is informative (not normative), and it’s only one of possibly many ways to achieve the guideline 3.2.2.
So it can be conforming to have no submit button, for example when
the user has been advised of the behavior before using the component
Related technique: G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
The important thing to note here is that a change of content does not immediately mean a change of context.
From a 3.2.2 guideline perspective, your select box is highly likely to be perfectly fine.
A change of context means a really drastic change. Something like when the user selects an option in the select box, focus is shifted to a different section of the page. Also things like causing a full page refresh or opening a new tab will also fail this criterion.
WCAG "change of context" definition
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
user agent;
viewport;
focus;
content that changes the meaning of the Web page.
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
So if all you are doing is modifying some content elsewhere on the page and not messing around with the users focus point, you are doing everything just fine from a 3.2.2 guideline perspective.
You are currently failing in another way though
There is one thing that is causing your select box to fail accessibility. It is lacking a label. This is a fail against guideline 2.4.6 Headings and Labels. The lack of a label means that users will not know what the select box is for.
<form action="#">
<label for="unique-id">Label for select box</label>
<select id="unique-id" {... all that other junk ...}>
{...<option> elements...}
</select>
</form>
This a pretty simple question (I assume). Probably a repost, but I couldn't find the answer here... so here we go.
I have a checkbox on a page that I want to default to "unchecked" (unless I specify otherwise in my php).
When I refresh the page, if the box was checked, it will stay checked which is no-bueno because checking the box adds a dom element to my page via a function attached to the box. So the problem is if I refresh, the box is still checked, but the dom element doesn't exist (because I haven't fired the function and I don't want to unless the user checks the check box) but the box is ALREADY checked and I end up in opposite land where UN checking the box creates my dom element and checking it removes it.
Basically, the question is...
Is there a way to default a checkbox to unchecked without javascript?
BTW I haven't checked (no pun intended) in any browsers other than FF 3.5.10
See http://weblogs.mozillazine.org/gerv/archives/2006/10/firefox_reload_behaviour.html
(first comment):
It’s done that way on purpose so if you tap the refresh button you
don’t lose your work. There’s an entry in Bugzilla somewhere that’s
been WONTFIXed asking for a regular refresh to always reset the form
entirely. Basically it’s a backwards-compatibility thing — every
browser since NS1.0 (maybe even Mosiac) has done that.
Dynamically-generated pages don’t even reset themselves, though if the
expiration is set to 0 and you hit the back button it will give you a
fresh form. Also, if the form itself changes (add or remove elements,
change the action, etc.) the for will reset on a reload. I haven’t
tested it, but setting the form name to something random (assuming you
don’t need the name for JS access) might just work. Like ”> in PHP.
As you said, forcing a refresh clears the form, and resetting it does
too. Would something like do
what you want (again, not tested)?
this works for ie
autocomplete="off"
Sure:
document.getElementById('my_checkbox').checked = false;
Oops, I missed the part about no JS. As far as I know, Firefox retains page state on refresh, so I guess there's no other way.
In fact, you just have to add the <form> tag with attribute autocomplete="off":
<form autocomplete="off">
<label for="checkbox">
<input type="checkbox" id="checkbox">
</label>
</form>
You can use the parameter autocomplete="off" directly on the input tag