Improve visibility of Seven's smallest font elements

I think creating a patch for this could be a good task for a new contributor.

Changed the body font-size to 1em

This applies nicely. The new one is the one on the left.

What is the scope here? There are many other places in Bartik's style.css where the font size is specified at less than 1em. Seven's base.css also has assigned a font-size to 'Body' that is 81.3%. Most of these are probably appropriate(tables, etc.). Is this issue just looking at 'first page', or is it intended to establish best practice?

Actually, since I also have old eyes, I'd recommend including a similar change to the 'body' attribute in Seven's seven.base.css. Since a frequent activity with any theme is to look at the administrative menus.

According to comment above I've added needed styles to seven.base.css.

i testet the patch and it works for me. in seven and bartik font-size is now 1em.

Why would 87.5% be a good idea anyways?

I'm attaching a screenshot.

I wasn't sure if simplytest.me didn't do some css overrides so I tested current clone with and without the patch, as shown in the attached image(with patch on right). Note my browser default font size is set to 18px. Since seven is the default theme for install, it also has a large affect there, which some may not like. I think that should be looked at before this goes in as is.

Yup. This is true.

It might make more sense split this up so that it can get noticed in Seven's issue queue too.

I tried again with my browser set to 16px, which is the normal default. I didn't find any pages during install that scrolled now but didn't before. So I think it should be set back to RTBC. I would like to find out why Bartik and Seven assume assume that ~13px is the most desirable base font size for their themes. I found references stating this but no justification, as if it were an industry standard.

Is there a tag we could add to this to get a css designer to look at it?

I would like to add a reference to an article I found while researching this that I found pertinent for today's Bartik. How we learned to leave default font-size alone and embrace the em . Following this, we should delete the font-size specification, rather than modifying it.

For Bartik we probably want to just remove the font-size declaration, I don't think adding font-size: 1em is doing anything :). As for Seven, it might make more sense to leave it out of this issue as has been discussed. Seven has its own style guide and looking at this I'm thinking a vertical rhythm has been established that as far as I know would be broken if this patch were committed as is.

+++ b/core/themes/seven/seven.base.css
@@ -4,7 +4,7 @@
-  font: normal 81.3%/1.538em "Lucida Grande", "Lucida Sans Unicode", sans-serif;
+  font: normal 1em/1.538em "Lucida Grande", "Lucida Sans Unicode", sans-serif;

The problem for the Seven theme is that font-size is determined relative to the parent font size while line height is determined by the current font size. I modified the line height value for Seven and I think improved things, but vertical spacing just can't be consistent with the old settings, if for no other reason than line overflows occurring differently. In the attached images, unmodified images are on the left.

Please Read: Em vs. Percent ( http://kyleschaeffer.com/development/css-font-size-em-vs-px-vs-pt-vs/ )

Tried the use of 100% instead of 1em but didn't see much difference, but probably should use percent any way as the original code used percent. To me, the accessibility improvement to Bartik and Seven is worth dealing with slightly taller pages. But the design elements of Seven seem to be a sticking point right now and somebody else should comment. Guess I should look at the Seven design guide to see if this is a flagrant abuse.

Actually the current implementation violates the Seven Style Guide . From the Typography section:

"Body text is 16px/24px Regular. All text is 90% black (#1a1a1a) unless otherwise noted. A baseline grid of 24px is used throughout, relatively strictly for running text and for spacing between elements, less strictly within some UI components where other requirements come into play."

The current implementation gives 13px/20px. The body attribute should be '100%/1.538em'

Though this is such a small patch, this is one more iteration.

23: 2045473_23_Bartik_and_Seven_font_size_too_small.patch queued for re-testing.

+++ b/core/themes/bartik/css/style.css
@@ -2,7 +2,7 @@
   line-height: 1.5;

+++ b/core/themes/seven/seven.base.css
@@ -4,7 +4,7 @@
-  font: normal 81.3%/1.538em "Lucida Grande", "Lucida Sans Unicode", sans-serif;

The line height is now (slightly) different in both themes, right? For Seven, the line height is 1.538em and for Bartik it's 1.5. Should 't they both use the same line height to be somewhat more consistent?

Probably, since they are now applied to the same value. 81.3% of 16 gave 13.008 times 1.538 resulted in 20.006 for line height. 16 times 1.538 gives 24.608 for line height. Forget what browsers do with extra decimal points. Will fix, but still waiting for some comment about overall affect of this change from someone with good vision.

Woah, hold up a second. Isn't the whole reason we set the percentage on font size is so users can increase/decrease it at their preference. 16px is way too big for a complex UI. Note that the Seven style guide's typography guidelines are made with Source Sans in mind. For Lucida Grande it's way too big.

Users can still increase/decrease at their preference. And Bartik is not a complex UI. The discussion I've read, at least recent commentary, recommends 16px base and modification according to content. More text in a given area is not more stylish than readable text. This is an accessibility and design issue. If the font choice makes for problems then maybe Bartik needs some re-design, because I thought Drupal has made accessibility a priority.

There's an interesting article from smashingmagazine about body copy font size. You can read the article here.

"The problem here is a basic usability and accessibility issue: a good design should look good without requiring the user to enlarge or reduce the text size.”
- From W3, more here

We can't please everyone. Everyone has a their own preferences for font size. Some may prefer more than 16. I don't believe that there is a blanket rule: “All websites must now just 16px base font sizes”.

The typeface makes a big difference, here's a comparison of Source Sans and Lucida Grande both set at 16px.

Having said that, feel free to play around. If Bartik looks great at 16px then it's win win. It's a 100% design decision though. We shouldn't force this through.

A nitpicking update. This only affects Bartik and Seven. The net affect is greater accessibility at the cost of slightly taller pages for Bartik, install, and admin pages. True, 16px for body element font size is not a standard but the only survey I located showed that it is the most frequent, if not near a majority. However, I think 100% is recommended by the W3C, at least implicitly. And, if we can't please everyone, we can at least adopt a choice with a positive rationale, rather than the ambiguity of 'style'. I agree this is a design decision, which, of course, includes accessibility as a parameter.

This looks good to me. I like the "adopt a choice with a positive rational" approach @dcrocks!

Seven comparison 100%:

Bartik Comparison 100%::

RTBC++ good decision 100% on 100%.

We need more extensive testing than that. We use ems all over the place, so changing the body value changes everything relying on it, that a lot of potential broken pages. The headers are now different sizes and the installation steps look way too big. It's also broken the password indicator, which is set in ems.

Wow, its quite distressing this has been put to RTBC without thorough testing nor review from maintainers responsible on this front. @mgifford please notify maintainers, when such a big change is put forth.

I do not think the suggested font-sizes matches what we want to do with Seven. I know that the suggested size by W3C is larger, but it really screws up all of our pages - our design can't accommodate such a large font. Also keep in mind that Seven is an application interface, not a article interface - it is optimized for scanning. This also blatantly disregards all the thinking we have done around typography in Seven as shown in the style guide. As far as I am concerned, we cannot enlarge it to this extend in Seven.

@Bojhan - Sorry. No distress was intended. I had somehow thought you'd already seen this. I will be more careful in the future. As always your views are very important with this and other design issues.

So if not 100%, how much larger do you think we could take Bartik so that it was consistent with how large we could allow Seven? I can't make a call about how close we can get to 100% from the existing 87.5%. Maybe it's only 90% at this stage in D8 and we strive for 100% in D9.

@LewisNyman - Thanks for the additional screenshots with problematic areas. Thanks for setting this back to Needs Work.

Should be always compared on both Windows & Mac platforms. Ideally, it should checked on Macbook & regular laptops. I think if you're working on macbook retina all days, you seldom notice small font issues.

@mgifford No problem, I think its good for "major" changes to always get some visual design review.

I think its mostly about optimization for Bartik. I think 95% is as far as we can stretch it without having to change line height, etc. Though I already see some proportional issues with the links in the menu (body text too large in contrast to links in the menu). I am not sure if we still have a Bartik maintainer?

I would have to investigate Seven, we kinda tuned a lot of it already over the past year. As Lewis mentioned already its an application UI, to which other principles apply. We can obviously try to make it larger, but as Lewis clearly pointed out there are a lot of different interfaces to keep in mind (e.g. views, field ui, etc.)

Even on the many high res displays becoming available, 13px and lower is still a problem for some of us. It is clear that there is some serious font size compounding going on in Seven, possibly less in Bartik. It won't be easy to fix that but I would hope that both would try to improve their accessibility to a broader range of viewers.

@dcrocks I would consider separating this issue for Seven and Bartik. Seven is I think harder, and possibly we should try to bump text more selectively.

I think that would be better too, but I think the problem title is a little too simplistic now. Possibly rationalize/optimize font size choices for bartik/seven?

ps. I checked and there at least 14 different css files that affect the display of the install pages.

I think it might be easier to split Bartik and Seven into separate issues? The rationale and considerations are different for each.

I created a new issue for Bartik.

Updating the title to sound like a feature request and knocking down from major, feature requests can't be major :-)

I'm finding the detail text too small even at 175% zoom.

Simply setting the body font size larger doesn't work because it distorts the display too much. What I have focused on is leaving large elements the same size and trying to make sure there are no elements smaller than 1em. It seems the tweaking can become interminable. And, of course, there are other distractions.

@dcrocks That sounds achievable, do we need to change the title and issue summary?

Changed summary.

Just trying to tackle some low hanging fruit. I updated style.css and vertical-tabs.css to up every font-size under 1em to be 1em. There were no other font-size declarations in Seven that I could find. In my testing there doesn't seem to be any regression in layout or design.

There was also one instance of a font-size being set to 12px (line 1256 - .views-ui-display-tab-bucket h3), but upping that to 1em also didn't result in any regression.

I tested this locally, checking the admin pages and it seems like setting these font sizes up to 1em does make things a lot more readable. I agree with dcrocks that the tweaking could become interminable if we try another approach. I checked through the css files in seven and with this patch there are no font sizes below 1em now.

Hey, can we please get a before/after screenshot? Just so it's clear what has changed in the UI? There are a lot of changes here.

+++ b/core/themes/seven/style.css
@@ -1254,7 +1254,7 @@ details.fieldset-no-legend {
 .views-ui-display-tab-bucket h3 {
-  font-size: 12px;
+  font-size: 1em;
   text-transform: uppercase;
 }

I think we should not touch the Views UI. It's fragile and I think that any design change needs to be considered with the rest of the UI

One more point, if we are just setting everything to 1em, do we need a font size property? Isn't the default 1em?

Agreed on removing the font size declaration altogether if it's just 1em. I've done just that, and removed whole rules that were nothing but said font size declaration. Also: Screenshots!

Just double checked vertical tabs, as well - see the screenshot:

This is the one place I've observed any particular ramifications of changing the font size declarations (see the pink arrows).

The summary text on vertical tabs, which once fit nicely on one line, sometimes runs to two lines.

That being said, I see this as an acceptable change. There will be lots of vertical tabs, with lengthy summary text strings, that will inevitably run to two lines. It just so happens the the default summaries on the default content types happened to fit on one line, but now no longer do. I also think it's a price worth paying in the interest of readability.

Updating status.

I would like to make one other suggestion: Change the body font size from 81.3%(13px) to 87.5%(14px), which is the same as Bartik. That slight tweak is still positive without distorting anything in the current patch output. I tried the patch as is and with that change and found the output slightly better for my eyes without adding any additional distortions.

I tried the patch as is and with that change and found the output slightly better for my eyes without adding any additional distortions.

Which pages did you test? This change requires us to test every page. We can try this but only it's done properly.

Adjusting the body font-size is not within scope of this issue, thats exactly the things we wanted to avoid.

I am really not so sure about these changes, the text in the configuration screen looks ridiculously big. The form labels vs. descriptions balance is now so off, that its not a small size tweak anymore - there is a big difference between the two.

I don't know, all of this text is highly optimized - now it just feels like we are making it all out of balance. I am still really unsure about this issue in general, we don't have incredibly small fonts like other platforms and our interface zooms very well. The small tweaks we do, won't be enough for those with less sharp vision.

Tweaking a completed design is difficult. But using browser zoom introduces even more distortions and this patch thus far does minimize them. I would hardly consider the text changes on the configuration page going from 12px to 13px, as 'ridiculous'. I admit I am more concerned about readability than aesthetics, and though I don't think this patch goes far enough I am concerned that if nothing is done now, there will never be any improvement. If the core themes are redesigned for D9 I don't think there will be any more effort to improve readability for the many(if not the majority) of people with less than 100% visual acuity than there was going from D7 to D8 if some stand is not taken now.

Improvements are fine but we are not in a position where we can introduce design regressions. Why don't we optimise how we handle user zooming instead of trying to remove the need to zoom?

No idea as how to go about that. But still consider #55 an improvement, of both accessibility and usability, and not a regression.

I guess I'm not clear as to whether or not the change as I pointed out in #56 is considered a regression. I don't think it is, for the reasons I outlined in that comment.

As far as I could tell, the text defaulting to a calculated 13px didn't really affect anything else.

#63: Again, the issue with zooming is that it makes everything larger, not just the things that are too small. This can result in other things becoming too large to read easily.

For example, the largest text might become sufficiently large that it gets pushed outside the viewport.

The idea is to reduce the ratio between the smallest text and the largest text by making the smallest text sufficiently large without disturbing the larger text, which is already large enough without being excessively large. Zoom does not accomplish that.

With all that's be done to seven in the last 2 months, this needs reroll.

I'm going to take a look here.

I have made the manual reroll.

You have some overlap with #2346791: Remove id selectors from page template of Seven /

Not sure I'm qualified to mark this RTBC or not, after all (not a themer).

An automated CSS regression test would be nice here. Anybody know of some tools we can throw at this?

This is not novice. And #56 has screenshots.

Is this going to have to get bumped to 8.1.x.?

No, and this is no feature request - its an a11y related change.

It is a feature request. There's an easy feature for accessibility that is built into all browsers, increasing the font size.

Ok, makes sense. Though we need better distinction - because OS's also have loads of features around a11y (e.g. high contrast mode) and yet we don't depend on them. Saying we do depend on this one in browsers, and therefor mark it a feature request - seems like a one off.

Yes that is true, maybe the distinction is where we support these OS features instead of eliminating the need for them.

We have it built into our CSS best practices to support browser font resizing, we use ems instead of pixels. to achieve this. Another example is the Drupal.announnce JS library which is built to allow core/contrib to easily take advantage of an OS feature.

Sometimes it feels like we are throwing the baby out with the bathwater, when we push a change through under the 'a11y' banner.

It isn't as if this is a recent issue. Before this issue was created I know I made comments about this in D7 Seven and Bartik issues. It would be sad to keep pushing this back. And I'm not optimistic that any Seven successor nor Bartik would address it either unless it was addressed here.
Besides the 'ally' banner, I just think from a usability viewpoint small font content tends to be ignored content, sometimes with unwanted consequences.

Besides the 'ally' banner, I just think from a usability viewpoint small font content tends to be ignored content, sometimes with unwanted consequences.

That's an intentional design decision, hierarchy. Not every piece of text on the page has equal value, so we emphasise more important text using font size.

The latest patch removes hierarchy, so it's a design regression:

I would rather we ensure that the theme supports text resizing rather than introduce design regressions. If we can increase font sizes without regressions then let's do that instead.

We are talking about a browser. Drupal isn't the only page I visit. I already have the base font size set in my browser to larger than the default. There isn't any 1 or 2 or 3 things I can do to make my browser work with all the sites I visit. I don't expect I have any choice about this.
The problem with Seven and Bartik is that they both reduce the base font size significantly, making 1 em 14px and 13 px respectively, setting the base or 'normal' font size of the hierarchy to a small size. But changing those values won't work because the hierarchy doesn't expand well via multiplication.
This patch addresses this by flattening the hierarchy, including more elements into the 'normal' font size without disturbing the larger elements. I'm involved in this issue because I want to improve Drupal, so I consider this issue to be about a problem, or a bug fix, and not a feature request. I consider this a fix and not a regression.

The problem with using zoom to deal with this is that zoom makes everything larger, not just the thing that is too small, making the largest text cartoonishly big.

One question would be whether the themes respect a browser setting of minimum font size, as opposed to zoom, without causing obscuring or overprinting of text. This setting is available in Firefox's advanced font settings. I remember it being in Safari, but don't have a Mac handy to confirm whether it is still a feature.

Patch no longer applies:

error: patch failed: core/themes/seven/css/components/breadcrumb.css:2
error: core/themes/seven/css/components/breadcrumb.css: patch does not apply
error: patch failed: core/themes/seven/css/components/help.css:1
error: core/themes/seven/css/components/help.css: patch does not apply

Rerolled on 8.0.x

@njbarrett - So no changes from #72 other than the reroll?

There are some elements which need work based on @LewisNyman mentioned in #85.

@mgifford - No I just rerolled it so the patch applies. Still new to contributing :)

No problem. Do you have time to try to address some of the other issues that were mentioned?

Your re-roll seems fine. Bot likes it. Let's see if we can get you a patch in Core.

re: #85. All this patch does is flatten the bottom of the text hierarchy, so important text remains important and unimportant stays unimportant, with the reward of improved usability. So I wouldn't consider this a regression, but rather an improvement to accessibility.

I've rolled a new patch that improves the font size for many elements, and addresses the concern in #85 with regard to vertical tab descriptions. If we increase the size of the vertical tab title, then we would have to increase the size of all labels to maintain the design proportions. I propose setting the descriptions to 0.95em - only a minor decrease in size but still noticeably smaller than the title of the tab. Screenshots attached.

Hiding older files

Maybe Lewis can have another look at this. I'm actually still a big fan of #32 :P

Thanks for the screenshots @njbarrett. If you use dreditor, there is some handy embed buttons to easily embed the images in the comment.

#32 is probably too simple. There isn't any problem with the larger text items, just the small ones. I've given up on any significant redesign of the text items in Seven or Bartik. I can only hope that if a new core theme is developed someone actually thinks about this. But this last patch offers improved accessibility at little cost to the theme's UI. I'm hoping this can go in before 8 is shipped and the same solution can be applied to Bartik, which needs it more.

#32 is too simple, it seems like we are making good progress to ensure we don't introduce design regressions, thanks for the work.

Look

+++ b/core/themes/seven/css/components/form.css
@@ -85,15 +85,12 @@ label[for] {
 /* Filter */
-.filter-wrapper {
-  font-size: 0.923em;
-}

Looks like we need a screenshot of this element, which appears alongside the body field input

Also can we get a screenshot of tables with content in? There are a few that this patch could affect, such as field ui, block placement, and views listings.

Thanks @dcrocks and @LewisNyman. I'll likely be playing with something like this: http://typejs.org/ with min-max font-sizes for fun.

@njbarrett mind doing up the screenshots mentioned in #98?

Here's some screenshots of the filter wrapper and the views table.

I am happy with the changed here.

+++ b/core/themes/seven/css/components/panel.css
@@ -10,7 +10,6 @@
 }
 .panel__title {
-  font-size: 0.923em;
   text-transform: uppercase;

Sorry! I was going to RTBC but I realised that we don't have a screenshot for the panel title in Seven (/admin/config)

Also, I noticed that form-descriptions.png is a screenshot of the form descriptions, and help.png is a screenshot of the appearance page?

Rerolled patch file on 8.0.x

@LewisNyman

I've attached a screenshot of the panel titles - I actually think these might be too big now, as they are reverting to the h3 style in elements.css (see panel-title-patch-#103). Adding a font size: 1em makes it slightly bigger than the previous 0.923em. I uploaded a screenshot of this suggestion as panel-title-patch#104

Regarding help screnshots, this is the region that appears under messages on some pages. I attached another screenshot showing the difference on the /admin/modules page.

Ah yeah, for some reasons I thought .help was only for the help page.

In each situation I think the font size change has been minor enough to not ruin the visual heirachy of the component, in most cases the heirachy is communicated in other means, such as color.

Thanks for the hard work here.

Nice! :)

This is a task not a feature request - it looks like a usability and accessibility improvement. This issue is a normal task so we need to outline how it fits within the allowable Drupal 8 beta criteria. Can someone add Drupal 8 beta phase evaluation template to the issue summary.

Added the beta evaluation phase table

Back to RTBC, thanks @njbarrett for filling out the beta eval.

Committed 0c7e1e9 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.