Currently I'm creating a smart TV app for several brands.
A local equipment shop is willing to let me test the app on their televisions.
All bugs I found aren't that hard to fix, except for one on the Panasonic devices.
The app is launched through the Panasonic IPTV Apps Developers (HTML5) App SDK.
I have a login screen with several input-fields, yet when one is focused the keyboard won't show.
Because of this I can not enter any information and I'm unable to leave or change my focus in the form.
The first input-field has an autofocus.
I removed the autofocus thinking it had something to do with a focus event not registering or something similar.
But after a manual interaction with the input-field, the field is focussed but there is no keyboard that shows up.
Example of my HTML input-field:
<!-- Input username -->
<div class="row">
<div class="col-xs-11 col-sm-8 col-sm-offset-2">
<input type="text" class="form-control" name="username" id="username" placeholder="Gebruikersnaam" tabindex="1" autofocus>
</div><!-- .col -->
</div><!-- .row -->
Example of my Javascript to autofocus the input-field (after a successful login, I navigate a ul (my menu) with the arrow keys of the TV remote, hence the tab-index and forced autofocus.)
$(window).on("load", function() {
$("[autofocus]").focus();
});
Does anyone here know of another solution I can try that may resolve my problem?
You can try this-
In javascript the prompt() opens the soft keyboard.
You can try opening the keyboard on focus event of the input field and to make it auto-focused you can do this.
$(textFiled).trigger("focus");
Also, wait for the DOM to load completely. Hopes this works for your device.
I have been playing around with selenium webdriver library for python, I have some programming knowledge but almost none when related to webpages etc.
I am trying to login to this website https://freebitco.in/ I click on the login button, fill the textboxes and then click on the button with selenium but the page just refreshes leaving the inputs blank and nothing happens.
I have tried to manually (ctrl+V) inputing the text and then clicking on the button with selenium, in that case it works. I would love an answer for this fenomenon. I would also like to know how can a webpage differentiate between bot input and user input, from my point of view (no webpage knowledge) I can only see it being able to work with the guest timing etc to tell it's a bot or not, how can it see it is a bot writing in this textboxes? (if it is the case).
Thank you for your answers and forgive my poor english skills. (:
This is my code:
driver.find_element_by_class_name('login_menu_button').click()
driver.find_element_by_id('login_form_btc_address').send_keys(address)
driver.find_element_by_id('login_form_password').send_keys(password)
driver.find_element_by_id('login_button').click()
this is for the textboxes:
<input type="text" name="btc_address" id="login_form_btc_address">
and this is for the button
<input type="text" name="btc_address" id="login_form_btc_address">
From what I see on that page:
<li class="login_menu_button active">
LOGIN
</li>
So even though you are clicking on top menu, I think you are not opening login form Try to change the first click to be on link element:
driver.find_element_by_link_text('LOGIN').click()
Also you will probably need to synchronize between clicks (i.e. check that what you expected indeed happened)
so I have an app with several buttons:
<button tabindex='1'></button>
<button tabindex='2'></button>
<button tabindex='3'></button>
however tabbing ends up moving the tab focus to the actual tab of the browser instead of going to the next button (ie. it ends up focusing on Firefox's tab user interface instead of tabbing into the website's button)...any idea why this could possibly happen?
note: I can't paste in the real code I use since it is much more complicated and involves complicated javascript, etc hence it's difficult to paste them in into here however the change I made was that I made 3 button elements have tabindex attributes in ascending 1,2,3 order...
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
When a user inputs text on my Phonegap application then returned upon completion, the entire page is scrolled further than it should be.
I am looking for a workaround to ensure that, once unfocused, the page returns to it's normal position.
See image that illustrates issue:
http://i.imgur.com/ehdXCQq.png
I am using iScroll 4.0 but it is not active on this page.
How can this problem be rectified?
The way forward was to set a Javascript event to take it back to the top of the page (or wherever) once focus has been lost on the input box. This uses the onblur method (I guess the opposite of onfocus?) and really simply states that once focus is lost, the page snaps back to the top.
Here's the working sample:
<input name="foo" id="foo" class="foo" onblur="window.scrollTo(0,0);" type="text" />
...with, of course, onblur="window.scrollTo(0,0);" being the operative code to return to the top of the page.