Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form fields for Mobile #529

Closed
wants to merge 2 commits into from
Closed

Form fields for Mobile #529

wants to merge 2 commits into from

Conversation

brewerj
Copy link

@brewerj brewerj commented Jun 23, 2017

Proposed new subhead ("Form field controls") to improve mobile coverage for responsive design of forms.

If confirmed, add note "Developed with support from WCAG TA Project"

Could also add in resource section:
https://www.w3.org/TR/mobile-accessibility-mapping/#set-the-virtual-keyboard-to-the-type-of-data-entry-required

@brewerj brewerj self-assigned this Jun 23, 2017

## Form field controls for mobile

HTML5 form field controls should be used to automatically show the virtual keyboard. Placing labels above form fields is ideal for mobile layouts. On smaller screens, field labels may drop completely. Ensure that fields have text descriptions.
Copy link
Contributor

@yatil yatil Jun 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HTML5 form field controls should be used to automatically show the virtual keyboard.

change to:

When HTML5 form fields are used, a virtual keyboard that allows easier input of the data is shown automatically: For example, a number field shows a numeric keyboard, a date field a native date picker.


On smaller screens, field labels may drop completely.

Either say “visual field labels” or drop the sentence altogether (my preferred way). We could even say: “While some designs want visual field labels to be dropped, users prefer visible labels as they make the form easier to understand.”


Ensure that fields have text descriptions.

Unsure what this is referring to aria-describedby sections? Might be confusing to have labels and descriptions in one paragraph and not to define both.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with "users prefer visible labels as they make the form easier to understand"

Also confused by "Ensure that fields have text descriptions." - aren't these form labels?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. @yatil's edit is clearer even though it adds length, prefer the suggested sentence.
  2. +1 to putting more detailed label guidance for responsive/mobile design on a labels page (and point to it)
  3. Agree precision is needed in reference to the option to "drop" labels

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to Eric's version. Would drop last sentence. Agree it is confusing.

@yatil yatil changed the title Update labels.html.erb.md Form fields for Mobile Jun 23, 2017
@yatil
Copy link
Contributor

yatil commented Jun 23, 2017

I wonder if that should go to the labels page (as not everything has to do with labels).

@iamjolly
Copy link
Contributor

I agree with suggestions from @yatil for HTML5 form field use and virtual keyboard examples.

For these two sentences:

On smaller screens, field labels may drop completely. Ensure that fields have text descriptions.

We may need to provide more context about the design choice of hiding ("dropping") the labels on small screens and the responsibility to ensure the form remains usable and accessible with examples of 1) how to reflow labels visually to be above their fields, or 2) visually hide the labels and use other methods to describe the fields.

Putting more detailed label guidance for responsive/mobile design on a labels page may make more sense than adding it to this page, too.

@yatil
Copy link
Contributor

yatil commented Jun 27, 2017

Another note: In the WCAG 2.0 definition of labels, they are presented to all users.

label
text or other component with a text alternative that is presented to a user to identify a component within Web content
Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
Note 2: The term label is not limited to the label element in HTML.

I don’t know if we make that distinction throughout the tutorial, but when we talk about “dropping labels”, we probably want to be precise.

@yatil yatil added the mobile label Jun 28, 2017
@nrhsinclair
Copy link

Agree that additional clarification is needed.

@yatil yatil self-assigned this Sep 9, 2019
@yatil
Copy link
Contributor

yatil commented Sep 9, 2019

I’ll take a pass to use this great information and make a proposal (in the new design).

@brianelton
Copy link
Collaborator

Pulling together the suggested updates:
"When HTML5 form fields are used, a virtual keyboard that allows easier input of the data is shown automatically: For example, a number field shows a numeric keyboard, a date field a native date picker. While some designs want visual field labels to be dropped, users prefer visible labels as they make the form easier to understand.”

I am happy with this and can make a new PR unless there are other comments.

@lakeen
Copy link

lakeen commented May 9, 2023

+1 to:

"When HTML5 form fields are used, a virtual keyboard that allows easier input of the data is shown automatically: For example, a number field shows a numeric keyboard, a date field a native date picker. While some designs want visual field labels to be dropped, users prefer visible labels as they make the form easier to understand.”

or with just a bit of wordsmithing :

"When HTML5 form fields are used, a virtual keyboard appears making it easier to input data.
For example, a number field shows a numeric keyboard, a date field a native date picker.

While some designs want visual field labels to be dropped, users prefer visible labels as they make the form easier to understand.”

I'm ok either way.

@brianelton
Copy link
Collaborator

Updates covered in #721. Closing PR.

@brianelton brianelton closed this May 9, 2023
@brianelton brianelton deleted the brewerj-patch-4 branch May 9, 2023 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants