I am just starting with jquery.validation and like it. One reference I felt specifically helpful when trying to understand the big picture is http://docs.jquery.com/Plugins/Validation/Reference#Markup_recommendations. One part I didn't understand is why labels need to be associated with each input. Yes, I understand that labels are created to display error hints, however, these are different labels. I couldn't detect any change on the label tag, and it works fine without it. Anyone know why? Thanks
Each input has a label associated with it: The for-attribute of the label refers to the id-attribute of the input.
<label for="firstname">Firstname</label><input id="firstname" name="fname" />
In this case labelis actually HTML element that adds usability improvement for mouse users where if user clicks on the text within the element, it toggles the control.
In HTML label is an optional element, That means you don't need to provide label for each input
Related
I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
I am writing a very simple SPA application that has a single read-only 'output' field, followed by a single input field. When the user types an input command and hits enter, the JavaScript writes text into the output field. I want the screen reader to read this output straight away without the user having to navigate to the output field, so I added aria-live, thus:
<div>
<div class="output" aria-live="polite">{{myViewModel.output}}</div>
<input type="text" myAngularDirective />
</div>
In the first iteration this worked exactly as I wanted. However, some of the commands change the Url (though rendered using the same view) and I wanted to ensure that the focus is left on the input field, and in most cases, the input field is cleared for the next command. When I add code either to focus on the input, or modify it, the output still renders fine on the screen but is no longer read out by the screen reader.
I've tried:
Changing (in the JavaScript) the order of writing the output and
clearing/focussing on the input
Upping the aria-live to 'assertive'
Adding aria-live to the input also (not sure why I thought that would
help)
Moving the aria-live from the output field to the surrounding div
None has made a difference. If I remove the focus/clear logic, all works well again. There is some subtlety about how aria-live works that I am missing: any help appreciated.
It's difficult to answer your question without a reproducible code sample, and you haven't mentioned which browser and screen reader combination you were testing with. But, it may be that with your focus logic is overriding the aria-live="polite" setting. For example, when the page is updated, the aria-live announcement is queued (because aria-live="polite" is the least intrusive setting), but when the keyboard focus is then intercepted to keep focus in the `, this overrides the announcement.
I'm trying to interact with a widget on a webpage, enter data into a form element. But I'm getting an error saying the elements isn't currently visible so cannot be interacted with. When manually interacting with the page, the text box asks you to enter something, then that text goes away when you click on the box and accepts input. I've tried having watir click the box first but that isn't working for me either. Here is the raw html:
<input class="symbol-search ui-autocomplete-input x-defaulttext-ghost" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">`
after I click on the box in my browser that changes to this:
<input class="symbol-search ui-autocomplete-input" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">`
Suggestions? Not possible?
One potential problem is that the input element in your code lacks a 'type' attribute, which is what watir uses to distinguish things like text_field from checkbox (since they are all input elements, but act differently)
Without that type attribute (role doesn't really cut it, it's not even a standard element for an input field, not even in html5, not as far as I can tell
Lacking a type attribute, you won't be able to use most of the standard input types supported by watir, which means you won't have access to a .set method You are likely going to have to address this with the basic 'element' class, and then use something like .send_keys once it has been clicked in order to fire keystrokes at it.
Who's widget is this anyway? do they have a demo page that shows an example of it? that would make it easier for people to discover potential ways to work with the control.
This worked for me:
b.text_field(:class => /autocomplete/).set 'hello'
I have a simple question regarding usability.
Which is the preferred way of having place holders (empty texts) in text inputs:
A) Have them visible until user focuses the field.
B) Have them visible until user types the first character.
Most websites use the option A, probably because it's easier to do (just listen to focus event and clear the previous place holder text and reset text color to black).
However, I've seen option B also being used in a few random places. The way I see it, the pros are:
A
Simple to implement
Clear to the user
B
If you navigate a form using tab key, users typically press the tab before reading the next field in which case the empty text is already gone and the user has harder time knowing what to type. They would need to shift-tab to get the empty text back, then read it, and tab to it.
Another question: if the option B was used, should the empty text come back after the user removes the text (and still has the focus)?
i would certainly make input fields like twitter login page.
it is like your B way and has a very nice animation.
In the spirit of usability and accessibility, you should have a <label> that is always present. In my opinion the placeholder text is most effective when used as a helper, or indication of formatting, etc.
For example, you could have a signin form that requests username and password where the username is an email address. The placeholder could then be a sample email address that is cleared on focus (but the 'username' label is still visible).
Example (using HTML5 placeholder attribute):
<label for="username">Username</label>
<input type="text" id="username" name="username" placeholder="myemail#email.com" />
I have validation on all areas of a form, and within the inputs I have hints which are set in the input's Value.
However, the problem I have is that CodeIgniter see's the input as being filled in so a Validation error doesn't occur.
I know I can create a callback_function for each input, but with around 10 forms and 100 inputs I was hoping to avoid this and possibly create a generic function or rule?
Any help is greatly appreciated
You seem to be setting default values for your inputs when what you really want is a placeholder
So instead of this:
<input value="Enter your email" />
You want this:
<input placeholder="Enter your email" />
Depending on how you are setting up your input data, a single callback function could suffice if you really needed it, but really: Don't start hacking up Codeigniter for this. Just use placeholder as it was intended (see javascript solutions for older browsers).
Read more about it here:
http://diveintohtml5.ep.io/forms.html#placeholder
I am assuming what you mean is this:
Ghosted Values http://img864.imageshack.us/img864/8124/ghosted.png
Where the value in there is never meant to be the actual value?
The easy solution is to have a class on the <input> that indicates that it's using a stock input (and also it can grey the text out). When the user clicks in the field javascript can clear the initial value out for you (and remove the marker class).
You can then on the submit button click event go through the form and clear the values of anything with the marker class before you actually submit the form.