-
Notifications
You must be signed in to change notification settings - Fork 58
Forms page clarifications and improvements #46
Comments
|
Don't leave me hanging, Nick! |
@shawnbot |
Nice, thanks @andrewmaier. We should make this part of the guide if it's worth repeating! |
To summarize what I think I'm reading here:
...and we also need to update the form examples on the accessibility guide so that the markup is cleaner. |
Also my intention with that comment was -- please correct if I'm not interpreting the convo right! Thx, all! |
Ooooo, follow-up question to 1) --> |
I'm going to noodle on a good way to style this and get back to you (I'll likely start with something like
|
Closing as stale, on the assumption that the need will resurface if it still exists. |
@meiqimichelle and I have some specific questions regarding forms in one of the projects we're working on, but I think they're ones that could be answered in this guide:
<fieldset>
really need a<legend>
, and if so, what is the best way to hide it? Legends are notoriously difficult to style, and it would be nice to offer people an alternative (e.g., an<h*>
either in addition to or instead of<legend>
).<label>
with their text or not?<select>
elements, what is the best practice for an empty first option (value=""
)? Does it need text, or does the input need atitle
attribute? Or would a<label>
also suffice?Re: checkboxes and radio buttons, I have a thing for using
<label>
because it increases the hit area of the controls (clicking on the label clicks the corresponding input). Can we standardize on a method for this that meets 508 requirements?As a semantic markup stickler I also find the
<br>
distracting. Can we simplify the markup and just wrap those "lines" in<div>
elements instead so that consumers of this information understand we're not suggesting they use
and<br>
for accessibility reasons?The text was updated successfully, but these errors were encountered: