Background:
I am brushing up accessibility in this application.
The user must select one of the supplied answers to a question. The answers can be navigated between using the arrow keys on the keyboard.
When the user presses space or enter, the choice is made, and a new set of questions appear.
My question to stack overflow:
Is role="radiogroup" and role="radio" incorrect to use here, since it autosubmits and moves to the next question set?
Does radiogroup imply that the user would be able to change their answer before pressing a submit button?
If yes, what would be a better way, to indicate to a read speaker what this is?
Related
I have a button that cycles through states on click: {off, red, blue, green}
Desired behavior would be:
When first focusing the button it announces something like: "My button, Green"
When clicking the button it announces only the state, like: "Red"
Any advice on how to achieve this?
It can be difficult to make a user interface that isn't "common" to be accessible. For sighted users, is there a visual clue that the button has four states and that clicking on it, rather than performing an action, actually changes the state of the button?
This is often done with a "segmented button" that shows all the states possible and you click on the appropriate state you want. Very similar to a radio group. (The URL links to Apple's Human Interface Guidelines but the same concept can be used for web.)
You can potentially use aria-roledescription to describe how your widget will function rather than having a basic "button" role announced.
To manage what is actually announced, you could have complete control of what is spoken by the screen reader by having an aria-live region. I've posted on live regions several times recently so I'll just point to one of my previous answers (which in turn has links to a few other answers on live regions).
Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
I want to reveal some hidden text/elements(whatever) when some checkboxes/radio buttons are selected(assume there is a list of checkboxes/radio buttons to choose from).
What should I do to meet the WCAG 2.0 AA standards?
And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons.
Thanks!
Your last statement gives me pause: "And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons."
If you have non-standard behavior for your radios/checkboxes, will the sighted user be confused too?
With 'normal' behaving radios/checkboxes, the AT user will understand them just like a sighted person does - experience. You learn that a radio is a group of mutually exclusive choices whereas a list of checkboxes allows multiple choices. The screen reader will read the role of the object so the AT user will know what to do.
Now, if you're hiding/unhiding objects based on those selections, the AT user needs to be notified. That's typically done with aria-live. By default, an aria-live region will be read if the text changes or an object is added to the DOM which should include being unhidden if you're doing it via display:none. If you unhide by moving an offscreen object to onscreen, or changing the clipping rectangle, or changing the size of the object, aria-live will not help.
Also look at aria-relevant. By default, it's value is 'additions text', which is the behavior I mentioned above. If you need the aria-live region to be read on other conditions, look at the other values of aria-relevant.
I have to hide the length of the password being entered during login of my asp.net web application. I know the asp.net textbox server control has the textmode of password but I can't even show the that. Any suggestions on how to hide the user input?
<input type="password" name="password" style="color:White;"/>
seems close to your requirement but some browsers highlight input fields with yellow when you are in them. Setting the font size to 1px is another trick you could try.
But easiest might be to instead use z-index to put an image or colored DIV on top of the password field. Maybe an animated gif with a line of * characters that grows and shrinks randomly would be best - would totally confuse onlookers! :-)
How the user even knows the field is selected is another issue you'll have, maybe some extra javascript to detect and tell them that.
If you must (which I agree with #Ando that you shouldn't due to UI issues), I would use javascript (onkeydown) to copy each character to a hidden input field, and remove the key entered in the box.
This would allow you to retrieve the password on postback, while keeping the input field empty for the user.
Of course, if the user presses arrow keys, delete or backspace, you would have to decide how to handle that.
Hiding the length of the input seems like a really really bad UI idea from the users perspective, and you should argue that the specification should be changed.
While, I also agree with everyone else that is a bad idea I understand that some times you have to do things you disagree with.
I would have suggested what Mikael did but he already did it. :)
To recap:
I would use javascript (onkeydown) to
copy each character to a hidden input
field, and remove the key entered in
the box.
This would allow you to retrieve the
password on postback, while keeping
the input field empty for the user.
Of course, if the user presses arrow
keys, delete or backspace, you would
have to decide how to handle that.
You've said:
My issue with using Javascript and
storing in a hidden field is the user
viewing the source of the page and
seeing it.
I'm pretty sure that viewing the source should only show you what was originally downloaded not what the user has entered. However, there are tools (i.e. firefox addons) that can do this. You could store the value in a javascript varible and only put the password in the hidden field when it is posted or use some sore of ajax request to authenticate. However, With the right addons someone could find this as well.
If the issue is someone looking over the shoulder of the person logging in then these concerns (i.e. viewing source) won't matter unless the person who is logging in decides to view the source and show the person in which case it would just be easier for him to tell the other person his password.
Agreeing that its not the best idea...
1) When you start typing, on each key press, restrict a specific character from being entred as part of a password (eg pipe) then when the user types, add a ramdom number of pipes (eg between 0 and 4 pipes) then just remove these server-side?
2) Add these to a hidden field...if the user does a View_Source, they will only see the original value of the field, ie will be empty...just remember to clear the value if you need to depending on how its rendered (asp.net webform hidden field control) etc
3) Have 2 password boxes that need 2 passwords (just as bad an idea)
I confirmed the requirement with a security officer and apparently I miss read the requirement. However, I have seen Windows based applicatiosn perform this. The cursor moves on each key stroke but no star, asterik or bar is used. Thanks to everyone for theie suggestions and comments.
Just wanting to know if anybody has seen an example of a telnet/chat or other console like FLEX application where you can use the same TextArea as input/ouput area.
I've been trying to modify the app at:
http://livedocs.adobe.com/flex/3/html/17_Networking_and_communications_8.html
but so far, computer says no.
All the implementations I've seen use a combination of TextInput and TextArea.
The challenge is that we'll be using this app to telnet into some old routers and we'll need to do a fair amount of copy/pasting. Based on what I've seen, it seems that I would need to point the mouse into the TextInput in order to be able to right click and paste, which is not very sleak.....
Your thoughts,
Fran
edit Just realized that I had trimmed out what was directly pertaining to the question: I was unable to find anything that used the TextArea for input and output; see the below suggestions if custom-component suggestions are ok.
The TextArea component only fires a change event whenever a user adds input. Whenever you set the text field programmatically, a change event does not fire--you could maybe use that as a way to know what is user input and console "responses" by looking for carriage-returns (\r).
I'm unsure if you have a requirement to maintain the user's input at the bottom-most line (like a console), even after the console responds with something like auto-complete. If that's the case, then something a bit more complex would have to come into play (such as remembering where the user's input started/ended) or the requirement of a single-component console needs to be reconsidered--sleek is nice, but not always necessary.