I have a form page that, while tabbing through near the end, rather than going to the next input field focus jumps to IE's own selectables (url bar, tabs, etc), and won't go back to page elements at all. It only cycles around the browser options. Even clicking an earlier input field to focus that then hitting tab once puts you back in the url bar.
This is a weird one, no amount of searching has found a single other person mentioning similar. It appears to be completely EI's fault, but I have to deal with it somehow. The site I develop for has to be completely keyboard accessible per the WCAG2.0, and this is a hard stop currently.
I've tested it quite a bit and found a bit of info, though the specifics I've found only make it stranger.
It seems to be related to the fixed footer IE adds to deliver notes about saved form info or partial loading and such. For one, if such footer doesn't appear at all, the page works fine. It there is the footer, when the tab jumps out it will land there if it still exists; if it has been closed by clicking then the jump will be to the url. Here is the interesting bit though- if you tab into it and close it by hitting enter with focus over the x, then the page works perfectly after that! The next tab after hitting close puts focus back where it was, and it then continues as normally expected. It has to be closed by keyboard though, closing with mouse leave the page totally focus-cursed unless you refresh.
The jump out point is always the same tabbing down, but if you click focus below that and shift+tab up it does still jump out, but between a higher point. With form elements wxyz, it is between y and z going down, but between y and x going up, so in either case it is upon leaving x.
Any ideas at all?
Edit2: I've been cleared to link the site. It occurs on South Moon Under's billing page. To get there, you have to put something in the cart, hit (guest) checkout, and fill+click passed the shipping page (dumby info is fine for this, Mr. Test). On the billing page nothing needs to be filled to see the issue, just tab down; the jump is between the giftcard number and pin fields. (reminder: only occurs if IE's footer appeared, and is worst if you closed it by mouse.)
Edit: The form is totally normal HTLM, and works fine in all other cases and browsers. I can post the code but it isn't interesting.
<div class="formfield giftcertfield">
<label class="label" for="dwfrm_billinggiftcert_giftCertCode">
<span class="requiredindicator">*</span>
<span class="labeltext">Redeem Gift Card:</span>
</label><!-- END: label -->
<div class="value">
<input class="textinput required" id="dwfrm_billinggiftcert_giftCertCode" type="text" name="dwfrm_billinggiftcert_giftCertCode" value="" maxlength="2147483647">
</div>
<div class="clear"></div>
<br>
<label class="label" for="dwfrm_billinggiftcert_giftCertCodePin">
<span class="requiredindicator">*</span>
<span class="labeltext">Pin Number:</span>
</label><!-- END: label -->
<div class="value">
<input class="textinput required" id="dwfrm_billinggiftcert_giftCertCodePin" type="text" name="dwfrm_billinggiftcert_giftCertCodePin" value="" maxlength="2147483647">
</div>
...And then a couple more buttons and such. The jump happens between these two inputs though (going down, it is between the first here and a checkbox in a different form going up.)
I'm trying to develop chrome extension to save users favourite urls, so user will click in a button and a popup will appear infront of the website he is visiting allowing him to save his url.
The point is when this popup is been shown while user vistiing google.com, user can't write anything in the popup because google's input is automatically in focus so what should I do to disable this behavior?
Note: This is only happening with google.com
Here is example of my code which is inserted in a shadow dom in any page:
<div id="popup">
<label for="add">Add custom bookmark</label>
<input type="text" name="add" value="" id="add" autofocus="" placeholder="Please enter an URL...(www.example.com)">
Submit
Close
</div>
You can disable the "instant research" feature by clicking on "parameters" onthe bottom of google.com page and then "Research parameter".
How can I open a keyboard prompt without touch on textfield when page loads? I also need to set the cursor on to that field so that keyboard will auto open to type easily.
My Code is:
$("#email").focus();
$('#email').trigger('click');
This will works only in firefox browser not in chrome and others. Also in iphone cursor is not setting on that field.
Please note we have autofocus attribute in HTML5 which does this without any javascript code.
For example:
<input type="text" name="fname" autofocus/>
You can refer to: autofocus example
I have implemented a popup that is triggered from a button on my webpage. This popup nearly fills the entire screen and prevents users from interacting with anything on the webpage until the popup is dismissed. This works well for sighted users, but when using VoiceOver on the Mac you can still navigate the underlying web page content, and the blind user would have no idea a popup window was presented.
How can I prevent VoiceOver from navigating every element on the page except for one div (and every element in that div)?
I know one can use aria-hidden="true" to hide it from screen readers, and I know one can force a focus on an element, but I'm not sure how best to accomplish this. Do I need to loop over the entire DOM and essentially hide everything then upon close unhide everything? Or is there a better approach, some ARIA property that defines this type of element that's presented perhaps?
A website that exhibits the desired behavior is Piazza. When you activate the Login button it presents a popup modal dialog and demands focus, and you can't navigate away from it until you dismiss the popup.
Implementing accessible modal dialogs correctly has got to be one of the trickier aspects of web accessibility, since there's just so many things to watch out for, on top of the usual issues of screenreader and browser compat and adherence to spec. Here's a summary(!), somewhat based on personal experience, this article from Smashing Magazine on accessible Modal dialogs, WAI-ARIA 1.0 Authoring Best Practices and this slideshow on the same topic.
(Note that you'll find some conflicting advice between these; this is somewhat due to differences in behavior between screenreaders/browsers and spec, and different authors having different positions on whether to stick to spec vs work with the screenreaders that real users actually use.)
Tell screenreaders it's a dialog: Add role="dialog" to the parent DIV, and set aria-labelledby to point to the ID of the title.
This causes the screenreader to recognize the piece of UI as a dialog in the first place; when the user navigates into it, either by navigating or because focus moves into it, the screenreader will announce that the user is now in a dialog, and will likely also announce the title. (On some screenreader/browser combinations - notably VoiceOver+Safari, it may also affect how screenreader navigation works.) This alone does not 'hide' any of the other UI on the page, however.
Add basic keyboard support
There's a bunch of things to do here that are important for both screenreader users and non-screenreader using keyboard users. Two key issues here are to move focus to somewhere appropriate in the the dialog when it initially appears, and when the dialog is dismissed, restore focus back to where it was when the dialog originally appeared.
Make it modal for screenreader users and keyboard users
Dialogs come in two flavors: modal, which don't let the user interact with any other UI while present, and modeless, which do let the user leave the dialog and return later - examples might be the "Find Text" dialogs in some text editors. role="dialog" doesn't distinguish between these two cases, and also using ARIA doesn't have any affect on browser behavior, so if your dialog is modal, you have to do extra work yourself to make it behave as modal. There's two aspects to this:
Just as modal dialogs use a gray scrim or blur effect to visually hide the inactive background from sighted users, we also want to hide this content from screenreader users: otherwise they will still be able to navigate out of the dialog to the background, or use other hotkeys to list links or headings or other controls from the page and will see both items from the background part of the page and the dialog. In the past, putting aria-hidden="true" on all other top-level DIVs was the best tool to use to do this (and a bit fiddly - remember to remove it when done!), but as of 2020, aria-modal="true" appears to be decently supported and is much easier to implement.
For both screenreader users and non-screenreader-using keyboard users, you also need to make the keyboard behavior modal: hitting tab from the last item in the dialog should wrap to the top of the dialog, and the inverse behavior for shift-tab. If you don't do this, keyboard - and screenreader - users can simply tab right out of your dialog into the background of the page. There's different approaches for doing this, most involve tracking focusin or similar at the body level, and forcing focus back into the dialog if it "escapes".
Other tweaks/fixes/hacks
Windows-based screenreaders such as NVDA and JAWS go into "application mode" when they enter a dialog: their web navigation hotkeys no longer work, and they treat the content of the dialog as a form rather than a rich web page. This is fine is the dialog content is a classic form with just fields, labels and buttons, but isn't a good fit if the dialog contains web content with text, hyperlinks, and the like. In that case, you might want to place a <div role="document">...</div> within your role="dialog" but wrapping the main content.
Ensure dialog content is itself accessible
Should go without saying, but all of the above counts for nothing unless the content within the dialog is itself accessible.
Most importantly: understand why you are making the dialog accessible in the first place, and test appropriately.
Unfortunately, at the moment (Jan 2015!) there's still a lot of variation in behavior between different screenreaders (also depending in browser used); it's almost like how browsers were with CSS a decade(!) or so ago. It's worth understanding why you want to make your UI accessible, figure out where most of your users are going to be, and test appropriately given the screenreaders they'll be using. From the most recent (Jan 2014) WebAim Screenreader survey, Windows readers - notably JAWS and NVDA - have the majority of the market, with VoiceOver coming third.
Here's one possible strategy to consider:
If you just want to do a basic 'due diligence', then testing with just VoiceOver may be fine. The experience may not be as good on the other screenreaders, but if something works with VO, it's likely not going to be completely broken on the others.
Next level up is to get a copy of (free, but feel free to donate) NVDA windows-based screenreader and run it in a VM on a Mac (assuming you're using a Mac here). NVDA and JAWS tend to be pretty close behavior-wise.
If accessibility is part of your job description, then likely you or your company will need to get a copy of JAWS ($800+!), since that appears to be the screenreader of choice for government and educational institutions. (This is perhaps the accessibility analog of testing with downlevel versions of IE!)
You should iterate through all the top level items and set aria-hidden=true on those items. This is an example:
<!doctype html>
<html>
<head>
<title>aria-hidden examples</title>
</head>
<body>
<a aria-hidden="true" href="#">Link at top</a>
<p aria-hidden="true">Lots of text content</p>
<form aria-hidden="true">
<label for="input">Label</label>
<input id="input" type="text" />
<button>Submit</button>
</form>
<div>
<label for="dialogInput">Nother Label</label>
<input id="dialogInput" type="text"/>
</div>
<form aria-hidden="true">
<label for="input2">Label 2</label>
<input id="input2" type="text" />
<button>Submit 2</button>
</form>
<a aria-hidden="true" href="#">Link at bottom</a>
</body>
</html>
The problem is that this will cause the announcements to stay within the "dialog", but if you press the tab key, the focus can move outside the dialog and not get announced. This means that if there are interactive elements outside the dialog, the user could end up interacting with the wrong elements. Other browsers will do similar things.
So you will need to trap the focus inside the dialog using a Javascript event handler to handle your TAB keys if your page includes other naturally focusable elements like in the example above.
WAI-ARIA provides the dialog and alertdialog roles to define dialogs. The dialog role is used when the user is expected to provide data, and the alertdialog role is used to announce the contents of a dialog to the user.
Alert dialog
<div role="alertdialog"
aria-labelledby="dlgtitle"
aria-describedby="instructions">
<h1 id="dlgtitle">Shutdown instructions</h1>
<ol id="instructions">
<li>Open timesheet</li>
<li>Enter time for today</li>
<li>Close all open applications</li>
<li>Shut down system</li>
</ol>
<div>
<input type="button" value="OK">
</div>
</div>
Dialog
<div role="dialog" aria-labelledby="dlgtitle">
<h1 id="dlgtitle">Sign up to Newsletter</h1>
<ol id="instructions">
<li>Enter email address</li>
<li>Press the 'Sign up' button</li>
<li>You're all signed up!</li>
</ol>
<div>
<label for="email">Email: </label>
<input type="text"
id="email"
name="email"
aria-describedby="instructions">
<input type="button" value="Sign up">
</div>
</div>
WAI-ARIA Authoring practice design pattern for a modal dialog
I am making a mobile HTML page that has an input field. When I tap the inside of the input field, the iOS 7 keyboard appears. But the keyboard has a top ribbon that contains "<", ">", and "Done" buttons, as this
How to get rid of this top ribbon on keyboard? I want to keyboard style same as for safari address bar input and the iOS7 "Messages" app. Thanks!
its not possible due to the way iOS is designed,maybe in the future but for now we are stuck with this keyboard
As of iOS 9.3 this is not possible. (Unlike android) iOS is not open source so it's hard to prove but It's likely intentional because there is no other safe way to exit the keyboard. (Unlike android which has a back/close-keyboard button on swipe up or physically depending on the device).
The following is a list of border cases that one might expect to hide the done bar if it were possible to do so;
<span contenteditable="true"
<input tabindex="-1"
<input type="search"
only one input tag on the page
no form tag