Sync label text sizes

[ulde01]

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.

• [x] Bootstrap see https://github.com/sebgroup/bootstrap/issues/72
• [x] Vanilla see https://github.sebank.se/DesignLibrary/vanilla-pattern-library/issues/39
• [x] React see https://github.sebank.se/DesignLibrary/ReactComponents/issues/32
• [x] Angular material see https://github.com/sebgroup/seb-angular-material/issues/4

[hjalmers]

Its great to see the further push in this issue. I would love to see exploration whats done on these, I believe we all are visuals here. 

1. I think we are missing one value in this – line-height. As in Baltics we work with Estonian and Russan languages its high possibility to have label, instruction etc in two or three lines. I showed Jess how Russian language breaks the pattern for single line label into three line label. 

2. Another thing what I would like to suggest is description, thats not at the place as error. Please, take a look in my image below. Description would help if input is relly specific or additonal explanation is needed.

3. And the last thing is about the error line. I think its awesome that we have it. Question is how it would be built, as input field had 1px border. The way how line attaches the border is quite essential in my opinion. I would rahter go with 4, as then we can have corner radius 4 too in that line. As well, please, check the image.

// Mārtiņš

[hjalmers]

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).

Default

When form contains error

When form has no errors and has been altered

---

Line thickness

Regarding 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.

4 pixels

3 pixels (what we're currently using in Bootstrap theme)

2 pixels (proposed)

[splashdust]

One thing to be aware of is the way borders are joined when rendered in a browser:

All border joints in CSS are mitered, and this behavior cannot be modified as far as I’m aware.

In some cases we can get around it by adding style to an adjacent element, but in some cases that might not be feasible.

[mzemlickis]

@hjalmers About 1st and 2nd: That description below label might be too much, but content sometimes is really weird and hard to describe. I think we could skip that for now, if later needs for such thing rises, we can talk again.

@hjalmers is that error message 12? or 14?

[hjalmers]

@mzemlickis it's currently based on the "old" size which is 12 pixels (that's what we're currently using in bootstrap theme).

[ghost]

About the red/green line, why not just make it straight?

[mzemlickis]

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.

[ulde01]

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. Should I change it at the top or is it enough if I put the latest here?

Changes on labels

Forms Label: 16 medium (12 regular) Instruction: 14 regular Content: 16 regular (16 regular) Error: 14 regular (12 medium)

Error line (bottom of input fields, etc) Thickness: 4px

Input field, mobile Label: 16 medium (18 medium)
Content: 16 regular (18 regular)

Also interesting, but not focus at the moment:

List Label: 16 regular (16 regular)
Content: 16 medium (16 medium)

Table Table header: 14 regular (12 medium) Sub label: 12 medium (12 regular) Content: 16 regular (16 regular)

[ghost]

About margin & line height My eyes says it gets too tight between label & instruction if we set it to 8 px. Works fine when we have a one line label, but when the label is more than one line and there is an instruction text underneath it gets a bit to tight. How about setting it to 10? (I know the 8 is a bit holy...) Tried out two different line heights as well. To go with the size + 8 here gives to much space, are u with me? So, tried 16/20 on the medium label and 14/16 on the instruction. But I think we should go for line height 20 on both label and instruction. Give me your thoughts!

[conandx]

Is it only me who thinks it's slightly odd with instructions wedged in between label/field? Historically we have placed them under the field.

[ghost]

Maybe we can take height for both? Do you mean that it is the most common way to place an instruction text? Or the way SEB usually do it?

[ulde01]

Feedback on error messages: Funka (a Swedish accessibility agency) recommends error messages to be placed under the label and above the input field.

[ghost]

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 ;-))

[hjalmers]

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]

Label

Short error message [Form input]

Label

A very long error message that probably is too long [Form input]

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.).

[olagronlund]

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.:

<label for="password">Choose a password</label>
<input type="text" id="password" aria-invalid="true" aria-describedby="password-hint">
<div id="password-hint">Your password must be at least 6 characters long</div>

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.

[splashdust]

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.

[hjalmers]

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:)

[sndqst]

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.

[ghost]

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.

[hjalmers]

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.

[henrikhoglundseb]

About the red/green line, why not just make it straight?

I think the version @JessiNygrenWalhed has proposed is a great improvment

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).

Default

When form contains error

When form has no errors and has been altered

Line thickness

Regarding 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.

4 pixels

3 pixels (what we're currently using in Bootstrap theme)

2 pixels (proposed)

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.

[ulde01]

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! /Ulrika