-
Notifications
You must be signed in to change notification settings - Fork 1
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
Sync label text sizes #2
Comments
|
In response to 1 and 2, I think it's a great and probably necessary, an option which might not intrude so much would be to use the "feedback" area used for errors to give more help, like we do in the new login app (click images to show correct size). DefaultWhen form contains errorWhen form has no errors and has been alteredLine thicknessRegarding the line thickness I'd prefer to stick with 3px (what we're currently using in Bootstrap theme) as 4 looks really thick and 2 is to narrow in my opinion especially when the width is adjusted to show input progress try live example here. |
@mzemlickis it's currently based on the "old" size which is 12 pixels (that's what we're currently using in bootstrap theme). |
We should be able to keep input fields shape form even with the red line. I really can't find any specific argument why, but it just feels right if we are not changing bottoms radiuses. |
Great discussion! Don't think we have ever had this much involvement... good sign. :) I have an update to the details above, after @JessiNygrenWalhed has tested this some more. Images to follo. Changes on labelsForms Error line (bottom of input fields, etc) Input field, mobile Also interesting, but not focus at the moment:List Table |
Is it only me who thinks it's slightly odd with instructions wedged in between label/field? |
Feedback on error messages: |
Very good input! Think we should change guidelines, so both error text & instruction text always is placed under the label, above the input field. Ola, think you know if this is the right way to go according to Funkas guidelines. A good example would be if someone wants the text to be spoken, you should get the instruction or error text before information in input? (Sorry for the Swenglihs ;-)) |
I vote against putting the errors above the input although I agree that accessibility is important, the main reason being that since the error message might change as users input information, the input itself might move while the user is typing. Eg. Label (no error here)[Form input] LabelShort error message LabelA very long It works if we continue to build forms like we did 10 years ago though, then we only validated the form on submit (when users clicks save, go to next step etc.). |
I not sure where Funka’s recommendations are coming from. I would guess it might be a problem for people using screen readers to have the error message presented apart from the label and input field. However, much as you want to have the label connected to the input field, you can do the same for the error message, regardless of its position in relation to the input field. E.g.:
And Robert, please correct me or add information, since I’m way out of depth here :) So I would prefer the error message under the input field. |
Regarding screen readers, it shouldn't be a problem. As long as the error message is indicated as hidden (visibility:hidden, or display:none) until it is actually shown, and has role="alert" and aria-live="assertive" attributes, most screen readers should read the error message as it appears. This is assuming, of course, that error messages appear while the user is interacting with the form, and not after a page reload. |
My personal opinion is that we should design for humans and make it work for screen readers not the other way around. Like @splashdust and @olagronlund pointed out there are numerous ways to make sure forms are accessible (without altering the order), the most common one would be to use aria attributes (like aria-invalid, aria-live aria-describedby, aria-relevant, role etc.) and optionally show elements in the form using media queries targeting screen readers only. For those that are interested in ARIA, mozilla has a pretty neat explanation here that's not too technical either:) |
First rule of aria; don't use aria :) Designing for humans is making it accessible, and not just for sighted people. Luckily visually appealing design and a11y aren't mutually exclusive so there shouldn't really be a problem here, as already stated. Error text above the input field do has its ups, but visually I like it better under the input field too. Sure, the text might end up being obscured by an autocomplete panel (or mobile keyboard perhaps?) and loose its visibility but no solution is bulletproof. |
But when it comes to instruction text it should be placed between label & input, right? So it gets spoken in the right order. Now we have both options. And from what I understand SEB has always done the opposite. |
Like I said before I still think we should design for humans and not screen readers. Funka probably recommends a certain order for elements based on outdated development practices and browser behavior. Like @sndqst stated, the first rule of ARIA is not to use aria attributes to override the default behavior of standard elements, but when things like errors are added dynamically to a page and when we’re using custom components aria is there to help and there’s a property called aria-flowto which can be used to determine reading order for screen readers. I also think the describedby property would work too without needing an explicit order. |
I think the version @JessiNygrenWalhed has proposed is a great improvment
I think the proposed version (pic 3) with a 2px red border is the best alternative. When i worked with errorstates in suitability tool (rådgivningsverktyget) it became very obvious that 4px border was too much when 6 fields got validated with the warning. The whole screen was perceived as an error and the customer felt overwhelmed. We ended up override the design lib and make the border 2px. It wasen´t perceived as a problem anymore and the errorstate is still clear. |
I am breaking out the discussion about the error line to #13 . Please continue the discussion there. This issue focus' on label size. Thank you! |
As of 2018-12-11
Labels
font size: 16 px (1 rem)
weight: medium
line height: 20 px*
distance from input border to label: 8 px*
Input instruction
font size: 14 px (.875 rem)
weight: regular
line height: 20 px*
distance from input border to instruction: 8 px*
Input error text
font size: 14 px (.875)
weight: regular
line height: 20*
distance from input border to error text: 8 px*
*Note that 8 pixles and line height 20 refers to actual pixels in design and not margin-bottom: 8 pixels and line height in browser, due to line height affecting actual space between input and text.
The text was updated successfully, but these errors were encountered: