Develop Reference

How to display radio button on an alert box

Is it possible to have a radio button in an alert box?
The requirement is, not to use any modal box, that why we just think if it's possible with alert box or confirm box. then we can good to go.
Any help will appreciate.
Sample Screenshot is below.

i don't guess. i know that this is in fact impossible.
the reason is simple:
alert(), prompt() aswell as confirm() were part of html + js since js exists.
they never got deprecated though they break the asyncronous flow of javascript.
this is essentially why they only allow you to play around with strings.
they were never intended to be feature rich.
they were actually invented out of the blue because the inventor (Brendan Eich) thought they'd come in handy. (wich at that time was more than enough for everyone)
they are by design blocking operations and should be avoided as much as possible.
to get around them simply create a so called modal dialog (thats basically a <div> with position: fixed above the pages content.
benefit:
you can easily make it appear as you want and you would not break any network connections or behavior of your application.
PS:
don't use w3schools as reference for learning or anything else.
they are a low quality database. you should look stuff up on mdn or other sites but should seriously avoid w3schools since it's not feature complete on any topic.
keep in mind this is an opinion.

It is impossible to use radio inside of alert window.
Message parameter in window.alert(message); has a string type and you cannot put Object or HTML there (will be transfomed to string).

Do not overuse window.prompt() Method , as it prevents the user from accessing the other parts of the page until the box is closed.
Window prompt Usage Note

option element onclick event fix for chrome

I am probably wasting my time with this question but here goes.
Chrome and Opera do not handle events in option elements IE and Firefox do.
So I am wondering I some knows a workaround other than using onchange in the select element, as I have tried to work with that event and pull errors of null value.
onchange="side_nav(this.getAttibute('id'))"
The code I am using is simple id change that works sweet in anything but option elements in chrome and opera, This is the function.
function side_nav(id)
{
document.getElementById("selectedS").setAttribute("id","");
id.setAttribute("id","selectedS");
}
Like I said it works with this in the option element but only in IE and FireFox
onclick="side_nav(this)"
The function works sweet in buttons and I suspect every other element also, just not the one I am set up to use.
I suspect I will have rewrite the nav panel to fix the problem, but thought I would ask someone else there thoughts.

This is What I believe is the answer. not well written but addresses the issue with an answer.
This is a response to Chrome bug reporting. The actual post
Fist I must say after further evaluation I believe that this is not as much a bug or defect but is in how the browser handles the select and option elements. As I see this the browser sees the option element/tag more as an attribute of the select element rather than than an individual element. The select element/tag is just a multidimensional array in HTML and the option tags become attributes of the select element which is why events do not fire and is also why it is impossible to style the option element/tag. I see now that this is deep in source code and seems to be split up equally between the top four browsers. I'll put the basic select code that I have been working with but it will be of no help as it is just the norm, and as I said, it's not a bug but program design.
Thanks for the response.

Firefox Document Inspector, Firebug & Webkit Developer Tools (Chrome/Safari) not updating HTML to reflect checked status of checkboxes loaded via AJAX

This one is absolutely baffling to me as a veteran UX developer.
I have some content being loaded via an AJAX request initiated when a user checks a box at the beginning of an unordered list. When the box is checked, the list is populated with list items each containing their own check boxes, which default to state "checked".
From this point forward, if I right-click the checkboxes and "Inspect Element", the results are pretty strange. Upon checking or unchecking the top-most box, the results are as expected: the box is checked or unchecked, and in the inspector, this is reflected within the HTML. Therefore, when checked, a new attribute is created (checked="checked") and the state reflects what is seen in the HTML within the page itself.
For those check boxes which were loaded via AJAX, the results are NOT as straightforward (or correct). It IS possible to check and uncheck the boxes in the list, and when submitting the form, the results ARE accurate. When calculated on the fly using jQuery or regular JavaScript, the values of these checkboxes are reported accurately.
However, within the Chrome Developer Tools, or the Firefox Document Inspector, or in Firebug, the HTML for these recently-loaded boxes is not accurate. They DO load with the same state as expected (i.e. they all load with their state set to on; e.g. checked="checked" in all cases). Nevertheless, when changing the state via the browser window, the HTML in the inspector is NOT updating. The reverse is also true: when updating the HTML inside the Inspector window, the browser window is not updating.
While I'm not sure if this is relevant to the problem, I'll include it just in case: the list in question is also being contained within a Bootstrap accordion (which resides, by default, in the "collapsed" state, but expands as the content is loaded via AJAX to provide a fluid UX experience).
I have tested this so far on Windows and Mac OSX Mountain Lion, using Google Chrome, Mozilla Firefox and Apple Safari. The results are consistent in all cases. I cannot figure out why this would happen in this manner. Any feedback is appreciated.
One last note: because of the AJAX request involved in this process, and because the server that provides the requisite response resides behind a firewall (as this is a subscription-based site that I'm working on), I'm not sure that I can provide an example of this via JS Fiddle. If, however, someone has input on how that might work, I'm open to the suggestion and would be happy to provide an example of this frustrating bug.
UPDATE:
I noticed when looking at the jQuery API documentation at http://api.jquery.com/prop/ that the W3C specification for checkboxes indicates that "the checked attribute value does not change with the state of the checkbox, while the checked property does". So, this might be a partial explanation of what's going on here. It doesn't however, explain why changing the attribute on non-AJAX-loaded content causes the page to reflect the changed state, and vice-versa.

After a careful review of the W3C standards surrounding this issue, it seems clear that this is a browser bug (albeit not a serious one). The discrepancy exists because the non-AJAX method being used was presumably chosen to be more "friendly" and maintain consistency between the code and the presentation, whereas the AJAX method is more respectful of the true W3C specification. Such is the result of any collaborative development effort.
For those who are hoping to avoid any such inconsistencies, I recommend you use the following syntax:
$('#some-id').prop('checked', true); // Preferred method for checking a box or radio button
... instead of:
/* DON'T USE THIS CODE!
$('#some-id').attr('checked', 'checked'); // Deprecated method for checking a box or radio button
IF YOU DO, IT'S ON YOU. */

Notify screen reader a page changed [duplicate]

Imagine you have a simple, single-page application - regardless of whether it was written using Backbone, Angular, Ember or anything else.
How can you tell a screen reader that we've changed 'page' when a route is followed?
In a classic application, when I navigate from /index.html to /about.html the screen reader obviously detects the page change, and re-reads as you'd expect.
In my Backbone application though, when I follow a route I cannot work out how to trigger a 're-read'. I've tried triggering a focus event which I'd seen somewhere, but that doesn't seem to work.
Note: I'm currently testing with NVDA/Chrome.

Overall, you should not need to trigger a 're-read', and depending on your UI that might not be a good thing anyway.
My experience has been with angular.js (as an accessibility person rather than the developer), and our overall approach was to manage the focus rather than trigger a re-read. (We do extensive accessibility testing.)
The key thing from a UI point of view (primarily for screen reader users) is that selecting a link (e.g. about.html) should take you somewhere.
In this case the appropriate place to put the focus would be the top of the content area of the about 'page', hopefully an <h1>.
In order for that to work the target element should be focusable via a script, so probably needs tabindex unless it is a link or form control:
<h1 id="test" tabindex="-1">
The -1 means it is not in the default tab order, but is focusable via a script. See more at WAI-ARIA authoring practices.
Then at the end of the function that loads the new content, including the tabindex attribute, add something like:
$('#test').attr('tabindex', '-1').css('outline', 'none');
$('#test').focus();
When adding tabindex dynamically it is best to do so in a line before the focus() function otherwise it may not work (I remember that from testing with JAWS).
To test this I would use either:
NVDA & Firefox, Windows
Jaws & IE, Windows
It is also good to test with VoiceOver on Safari/OSX, but that works differently and may not hit the same issues as a windows based screen reader.
You will hit a lot of issues with Chrome/NVDA as that is not supported very well, and end-users are very unlikely to use that. IE is ok with NVDA, but Firefox is best.
Overall, it is worth getting to know the WAI-ARIA authoring practices, particularly Using ARIA in HTML. Even though you are using a JS app, the browser (and therefore screen reader) is interpreting the resulting HTML so that advice is still relevant.
Lastly, if you are updating page content without the user pressing space/enter to activate something, you might find that JAWS/NVDA do not know about the new content as their 'virtual buffer' has not updated. In that case, you might need to add a JS shim to make them update, but only do that if you run into problems in testing, it should not be a global patch.

Taking the answer from #AlastairC, and the comments below it. I've taken this a bit further now and am going with this as my solution going forward:
My go-forward solution
I found that just reading out the first heading wasn't really that useful. Especially if the last page you were on was a loading sequence. You can hear that there something new has been focused, but it's certainly not clear that this forms the part of a whole now page.
Add some useful, descriptive text to the page
As such I now have a single paragraph at the top of my page layout template. This includes a screen-reader friendly message, along with a very rough overview of what the page.
<p class="screenreader-summary" tabindex="-1">
The <strong>Dashboard</strong> page is now on-screen.
It contains several widgets for summarizing your data.
</p>
Note that the tabindex value allows us to focus this element with JavaScript. You might not want to use a p element for this, you can use anything you like really.
Hide it off-screen (optional, only required if it would break your design/readability)
This is then coupled with CSS to move this element off-screen:
.screenreader-summary {
position: absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
outline: none; /* Important, don't show an outline on-focus */
}
Focus this element, when a new page is shown on-screen
Finally, in the JavaScript code that shows your page on screen (e.g. in MarionetteJS using onShow or the show event):
$yourViewEl.find('.screenreader-summary').focus();
The result
I'm a sighted person, so take what I say with a pinch of salt - however I found that reading out a short description is so much more useful.

For angular the url changes, If someone REALLY needs to reread everything, (like me because of requirements), what did the trick for us was this:
$(window).on('hashchange', function () {
location.reload();
});
and we just added extra code to handle pages like "success" were no reloads are supposed to happen.
this simulates the actual page loading, and screen readers will read it normally like a page change.
kind of defeats the purpose of angular in a way, but this will help people like me who already have the application, and want a quick fix.

Why do textfields become disabled in IE6 for no reason?

I have made few changes on this huge JSF page, which is full of Javascript as well. I dont know which change make the problem happen.
The problem is: after some Javascript is executed, all the text fields in the page become readonly. The problem is not occurring in IE7 nor in Firefox. I have debugged all the javascript, there is no errors thrown! And there is nothing telling the fields to become readonly, since its working correctly in IE7.
Not sure what the problem is, could be CSS related? or Javascript? And why is it happening on IE6 only?
Note: "Don't support IE6 is not an option"

While IE may be buggy make trouble in some situations, I'm quite sure this is not an IE bug.
How do you tell the fields are read only? Do you get any optical confirmation or is it just that you can't click them any more? In that case, I'll bet you a beer that is's some invisible DIV or other layout element that, due to some CSS setting, squeezes itself above the input fields.
Try the IE developer toolbar to find out whether it's a layout problem.
If they are really disabled as in <input disabled> you need to show some JavaScript or (better) a link.

Still not sure what happened with that build, but what i was sure about is all the Ajax modifications i did was responsible for the problem.
The scenario was like:
Fill textfield1 (hit getValues1 , then hit a validate Ajax)
Fill textfield2 (hit getValues2 , then hit validate on both values together)
Fill textfield3 (hit getValues3 , then hit validate on all three values)
And a forth time again the same scenario. The page was built by a new to JSF guy, and it was very huge. I took long time refactoring it. But now its much better, each text field still have a getValues Ajax, but instead of validating them after getting all the values, i filter the allowed values on the server by sending the chosen criteria
The scenario now:
Fill textfield1 (hit getValues1 Ajax)
Fill textfield2 (hit getValues2 Ajax with value of 1, and get only allowed values)
... etc
The problem seems to be an Ajax racing conditions and at some moment IE6 was hanging or stuck in a deadlock, im not sure.
Lesson learned, "Refactoring once may take a week, but without every single issue will take longer"

um... don't support IE6??? ;)
Suggest disabling your CSS and seeing if the problem goes away. I'm not aware of any CSS tags that can disable a field, though.
Other than that, debugging is your only option. Remove all your .js and add it back in line-by-line until something breaks.
It will probably be hard for us to help you without seeing some code.

See if the HTML for the page has the 'disabled' attribute set on those INPUT elements. If so, then javascript is being used to enable the elements after the page has loaded. This is a not-uncommon technique to keep users from prematurely trying to interact with a page before all scripts have loaded.
If that's what is happening, then what you've probably done is break the way the script recognizes which elements need to be enabled. Since this is only happening on IE6, it sounds like the script might be doing some esoteric DOM navigation, which broke as a result of changes to the markup or CSS.
Unfortunately this is something you'll have to debug by reverting back to previous versions until you identify the change you made that broke the page.

Based on the other answers here, and some of your comments to them, it seems there is a JavaScript function in your page that sets elements to be enabled or disabled.
In order to help, we would have to see your code. Here is something you can do yourself, though, that would solve your problem:
Find that function (or ANY function) that sets elements in your page to disabled or enabled.
Depending on your development environment, there are different ways to do this, but somehow add a breakpoint there at the function.
Load the page.
Whenever that function is called, code execution will stop at that function. Whenever it stops, make sure that it was supposed to be called (and watch the call stack).
Eventually, you'll hit that breakpoint at a point where you weren't supposed to. Look at the call stack to see what caused it (which function resulted in a call to this function).