Is there any cons of 2nd method?
Why http://www.webstandards.org/ decided to use 2nd method
Is first method better than first for
screen reader users?
First
<label for="name">Name</label>
<input id="name" />
Second
<label for="n">Name</label>
<input id="n" />
The only 'con' is that the id is non-descriptive. For a page with little content, this wouldn't be a big deal but for a larger page, using a descriptive ID is helpful in development. Too, ID's need to be unique, so the single letter approach would get old at input #26 :p
As a side note, webstandards.org might have run their html through a compression utility that changes their descriptive IDs into single letters to minimize download time. e.g.
Their in-house code is your first example and the compressor spit out your second.
I use this:
<label>
<input>
</label>
Related
I'm creating a from that has validation errors show below the related inputs. To make the form more accessible I have added aria-lives to div that will hold the error message. With having more than one aria-live will this make it worse for the users?
<div
id="awesome-id">
<label for="awesome-id--input">
This is a label
</label>
<input
type="tel"
id="awesome-id--input"
required>
<div
role="region"
aria-live="polite"
id="awesome-id--error-message">
</div>
</div>
<div
id="another-id">
<label for="another-id--input">
This is another label
</label>
<input
type="tel"
id="another-id--input"
required>
<div
role="region"
aria-live="polite"
id="another-id--error-message">
</div>
</div>
You can have multiple aria-live containers - especially since they are “polite”, they should wait until it’s quiet to give you the feedback. Whether this is also a good experience for your users, you should simply test with a screen-reader (or, preferably, conduct user-tests).
However, I would remove the role=“region”. This is the specification of the Region element at MDN Web Docs:
The region role should be reserved for sections of content sufficiently important that users will likely want to navigate to the section easily and to have it listed in a summary of the page.
Landmarks like Region allow the user to quickly navigate to them. But adding all error messages to that list of landmarks would just muddy it in my opinion. Instead you should consider adding role=“alert”.
Also, make sure that the error container having aria-live is present at the page on load - even though it is empty. Otherwise some browsers will not know to listen for changes in it.
Lastly, remember to also toggle aria-invalid=“true/false” on the input to provide the screen-reader with proper feedback.
I am facing an interesting problem: I have a form where I want to insert old values (if the form was submitted before) like this:
<input type="text" :value="oldName" id="name" />
Now the problem is that I can't overwrite the oldName variable like this, so yes, I have the old value in there, but I can't change it anymore. Can you think of a solution? I basically want the value to be in the textfield, but I want the user to be able to change it. Thank you!
Sounds like adding v-once to the input field would solve your problem. V-once means that oldName will be used to render the value once, but after that it will be a normal string literal.
<input type="text" :value="oldName" id="name" v-once/>
In case you want the user to be able to modify the value use v-model instead of v-bind. V-model provides two way binding so when the user writes something in the input field it is reflected in the value.
<input type="text" v-model="oldName" id="name" v-once/>
I want to make my input to only accept files from gallery instead of allowing the user to open the camera.
How can I achieve it?
ASP.NET
<asp:FileUpload ID="filGallery" runat="server" AllowMultiple="true" />
HTML 5
<input type="file" id="filGallery" multiple="multiple" />
The behaviour I want is similar to the one found in iOS 8 or less, where input with multiple files enabled couldn't open the camera
I don't think there is a way to force using gallery - current trend is more on using camera (and suggesting using front or back) rather than disabling it.
However, there is a similar question on SO (but focus on type of capture) where that answerer has pointed to some ways of input attribute you may try out:
original SO: https://stackoverflow.com/a/40512470/2564920
More detail test he has done regard to the mobile capture: https://addpipe.com/blog/correct-syntax-html-media-capture/
A test page which you can try out: https://addpipe.com/html-media-capture-demo/
specifically one setting which is
<input type="file" accept="image/*" capture="filesystem">
looks promising - but probably won't work (since this syntax is deprecated and capture attribute in newer spec is used to say you want to use camera - choosing between front or back camera source)
just use simple method to open gallery in mobile
<input type="file" id="fileProfile2" name="fileProfile2" accept="image/png,image/jpeg" capture="filesystem">
I have a page that is rendered through xulrunner service. There is a form and a button under the form.
For accessibility requirement, I forced the focus on the text field within the form when the user navigates to this page. However, sometimes JAWS always reads the Post Comment button label. Sometimes, JAWS reads the aria-label “Enter Comments”.
Here is the code:
<body onLoad="document.addcommentform.comment.focus()">
<input type="textarea" aria-label="Enter Comments" title="{$enterComment}" name="comment" />
<input class="Button" type="submit" value="{$postComment}" />
I also tried to put a visible label on the UI like this. I did more testing and found out the behavior is pretty the same.
<label for="addcommentform">Please enter comment
<form method="get" action="{$self}" name="addcommentform">
<textarea title="{$enterComment}" name="comment" class="commentarea" </textarea>
<input class="Button" type="submit" value="{$postComment}" />
</form>
</label>
I think it is related to this known bug https://bugzilla.mozilla.org/show_bug.cgi?id=133771
But does anybody known any workaround to this issue?
I'm a Jaws user and don't know of a way around this. Since Jaws tends to create it's own model of pages in a virtual buffer things can behave slightly differently then you would expect. To confirm or disprove weather it's a Jaws specific bug I would suggest trying out NVDA an open source and quite good Windows screen reader.
What is the right way of creating and processing a group of related controls on posted forms?
From using ASP.NET MVC I see a standard option is to create a number of inputs and assign the same "name" attribute value to them. Like this:
<input name="OrderOptions" type="checkbox" value="1" />
<input name="OrderOptions" type="checkbox" value="2" />
...
<input name="OrderOptions" type="checkbox" value="N" />
And when processing forms we get all the values in a comma delimited string:
public OrderController
{
public ActionResult (FormCollection form)
{
string selection = form["OrderOptions"];
}
}
Now, is this how it is supposed to be done with any server technology? Does assigning the same name value to inputs break some validation rules or something?
One extra question: If I were to use the built-in HTML helpers, I would get the inputs generated with both "id" and "name" attribute. Like this:
<input id="OrderOptions" name="OrderOptions" type="checkbox" value="1" />
<input id="OrderOptions" name="OrderOptions" type="checkbox" value="2" />
...
<input id="OrderOptions" name="OrderOptions" type="checkbox" value="N" />
But it is clearly invalid to have multiple elements with the same "id" in a document. Still, it works.
If I discard the standard helpers and make my own, do I need to insert the "id" attribute to inputs if I do not really need it (except in some label cases)? Some folks are telling we have to always assign both "id" and "name" attributes to elements because there is some incompatibility with old browsers, and the "name" attribute is deprecated (I know it is only for some other elements). But even if I wanted to, I would have to assign different id/name values for input elements and then I cannot process them as a group. You see my dilemma?
Any advice is greatly appreciated.
a) No. Assigning the same name is definitely valid behaviour -- it's how radio buttons know which group they're a part of (so that others in the same group turn off when you click one, while other groups on the same page are unaffected).
b) Yes, having the same ID is invalid. I have the same problem with the helper apps. It makes the entire page invalid and, for me at least, makes any javascript more difficult.
No, you don't need the ID. But if they exist they should be unique. Furthermore, I don't know about this whole "name being deprecated" thing. How else will forms work? Forms do not submit the ID when POSTing back. See http://www.w3.org/TR/html401/interact/forms.html#edef-INPUT .
If you choose to assign ID, they can be different without affecting group_processing. In fact, I'll generally name them something like "OrderOptions-<%= order.option.id %>".
EDIT:
PS: Use the html validator at http://validator.w3.org/#validate_by_uri+with_options . It'll catch and notify you of things like duplicate IDs or missing IDs. It'll also (if I remember correctly) tell you of deprecated elements/attributes that you use.
James