WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 weeks ago

#12825 closed defect (bug) (maybelater)

Largest minimum text size in FF prefs makes admin display terrible

Reported by: jane Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9.2
Component: Administration Keywords: has-patch 2nd-opinion
Focuses: accessibility, administration Cc:

Description

The backend looks great in FF if a user zooms, as long as they don't zoom text only. However, some visually disabled people use the Firefox preference for minimum font size instead, because doing full zoom means lots of horizontal scrolling. Is there anyway to make it so that a large minimum text size wouldn't be so terrible-looking?

To reproduce: in FF, go to Preferences, Content, Advanced Fonts, select 24 for minimum size. Look at the admin; eek! (In comparison, zooming to that size looks very pretty, but requires horizontal scrolling).

Gmail does it decently, so I thought it was worth asking, but I know that there may be technical reasons that we can't make it happen. Would just like to know what those are if so, so I can explain to users who ask about it. If we *can* make it happen, that would be sweet.

Attachments (4)

big_patch.diff (22.9 KB) - added by adamsilverstein 2 years ago.
big-font.diff (25.3 KB) - added by adamsilverstein 2 years ago.
switches fonts & heights from pixels to ems in admin, admin-bar
admin-in-ff-text-resize-01.jpg (107.0 KB) - added by GrahamArmfield 17 months ago.
Plugins page in Firefox with text nearly up to 200%
12825.diff (1.7 KB) - added by adamsilverstein 8 months ago.
use min-height instead of height

Download all attachments as: .zip

Change History (39)

comment:1 @designsimply5 years ago

  • Priority changed from low to normal
  • Severity changed from minor to normal

This link may also be relevant:
http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-text-scale

The ability to use the maximum minimum font size in Firefox is critical to some (for example, people with repetitive strain injury or RSI). Zoom does not address the issue because it requires horizontal scrolling to read each and every line.

Here is an example of the dashboard when set to use the maximum minimum font size in Firefox (taken from WordPress.com on 4/2/2010):
http://img.skitch.com/20100402-tb36e7u9h1sry5q8fsmaw1hyy5.png

comment:2 @designsimply5 years ago

Here is another screenshot illustrating this problem from a WordPress.com user:
http://img.skitch.com/20100504-9iyh8wmhd4fcg6gnmx3g82845.png

comment:3 @azaozz5 years ago

Unfortunately to fix this we would need to completely rewrite a lot of the CSS and I'm not sure if it's even possible to achieve while we still support IE6. Also fixing this would increase the width of many elements that will increase the screen width and create horizontal scrollbar anyways.

The best way to display large text on a computer monitor is to set the overall resolution to lover (and have big monitor). WordPress admin scales quite well in this case.

comment:4 follow-up: @toscho5 years ago

  • Cc toscho added

This problem exists not in Firefox only, but in all browser with such a setting (Opera, WebKit). Most of these bugs could be fixed if we’d use em instead of px for dimensions.

@azaozz Changing the screen resolution is a very bad workaround: It affects font smoothing and (background) images too, which isn’t necessary and looks often very odd.

comment:5 in reply to: ↑ 4 ; follow-up: @azaozz5 years ago

Replying to toscho:

Most of these bugs could be fixed if we’d use em instead of px for dimensions.

Yes, however using em would make all elements wider and create horizontal scrollbars on smaller screens.

Changing the screen resolution is a very bad workaround...

Changing the screen resolution seems the best workaround in most cases as it affects everything, not only the web browser. I actually know a guy with similar problems. He was using a CRT monitor as the text stays "sharp" on lower resolutions. However the LCD screens have evolved too. Recently he switched to a 24" LCD (1080p) that he uses on lower resolution with font smoothing turned off. He's very happy with it mostly because the screen is wider and there isn't any horizontal scrolling anywhere.

comment:6 in reply to: ↑ 5 @toscho5 years ago

Replying to azaozz:

Yes, however using em would make all elements wider and create horizontal scrollbars on smaller screens.

No, it wouldn’t. I’ll try to understand the interaction of the various stylesheets for the backend, and see if I find a working solution for 3.1.

Changing the screen resolution seems the best workaround in most cases as it affects everything, not only the web browser.

This is the very reason why it is often so such a bad solution: Just because you need bigger font sizes you don’t need bigger images, scrollbars etc. I'm using a minimum font size of 14—18px – but the last I want is wasting space for non text elements.

Anyway, accessibility problems cannot be solved by teaching the user to reorganize his OS settings around for a website.

comment:7 @nacin5 years ago

  • Milestone changed from Awaiting Triage to Future Release

comment:8 @grahamarmfield3 years ago

  • Keywords changed from text, font, zoom to text font, zoom

Now you're not supporting IE6 anymore is anything going to happen with this?

Text zooming and resizing are both really useful accessibility features and they are not the same thing (as is pointed out above). In some places using the word-wrap:break-word CSS property might help. It'd not be perfect but would stop some of the text clashing.

The tool bar height ideally needs to grow though to keep the larger text contained within it.

@adamsilverstein2 years ago

comment:9 follow-up: @adamsilverstein2 years ago

  • Keywords has-patch 2nd-opinion added

the attached patch swaps out ems for pixels in all font heights, line heights and some heights in wp-admin.css. on my test platform the dashboard looked better than the ticket openers, but i'm on a mac and didn't test on a pc.

here is the dashboard with firefox font minimum set to max size, without the patch: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.28.01-PM.jpg
and after: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.54.50-PM.jpg

it looks like the left column needs to grow as well, but thats more complicated (i tried), so far i just changed all the font sizes and heights (no widths).

i tested this patch in latest firefox & chrome & it looks fine, in safari i got smaller text overall, but still quite usable, looks like safari is treating 1em=14px, other browsers 1em=16px; didn't check ANY ie versions to see how they behave.

comment:10 in reply to: ↑ 9 ; follow-up: @grahamarmfield2 years ago

Replying to adamsilverstein:

the attached patch swaps out ems for pixels in all font heights, line heights and some heights in wp-admin.css. on my test platform the dashboard looked better than the ticket openers, but i'm on a mac and didn't test on a pc.

I'd be really cautious about using px to define font sizes - we may be preventing some users in some browsers from resizing their text at all which would be worse. I think it's a bad idea for that reason.

here is the dashboard with firefox font minimum set to max size, without the patch: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.28.01-PM.jpg
and after: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.54.50-PM.jpg

Having seen some people with low vision who rely on font resizing within their browsers I'd say that some would want the text to be even larger than the first example, let alone your second example.

it looks like the left column needs to grow as well, but thats more complicated (i tried), so far i just changed all the font sizes and heights (no widths).

I think you've hit the nail on the head here - it's that the design needs to change to be able to incorporate people's requirements for wanting text to be very large. The left column may need to grow, but certainly the toolbar at the top needs to be able to stretch down to accommodate large text which may of course force items on to a second line. The Help and Screen Options links need their backgrounds to allow resizing - as do the headings for each individual widget.

I believe that those who need text to be large will accept pages looking a bit odd as long as the pages are usable.

i tested this patch in latest firefox & chrome & it looks fine, in safari i got smaller text overall, but still quite usable, looks like safari is treating 1em=14px, other browsers 1em=16px; didn't check ANY ie versions to see how they behave.

IE testing is vital for patches concerning accessibility. As much as we developers hate IE, it is the browser of choice for many people with impairments as the accessibility options are good (and easier to find). Also much assistive technology including screen readers, speech recognition and screen magnifiers etc work best with IE.

comment:11 in reply to: ↑ 10 @adamsilverstein2 years ago

Thanks for your reply, i appreciate the input. comments below.

Replying to grahamarmfield:

Replying to adamsilverstein:

the attached patch swaps out ems for pixels in all font heights, line heights and some heights in wp-admin.css. on my test platform the dashboard looked better than the ticket openers, but i'm on a mac and didn't test on a pc.

I'd be really cautious about using px to define font sizes - we may be preventing some users in some browsers from resizing their text at all which would be worse. I think it's a bad idea for that reason.

just to clarify: i removed the existing hard coded pixel heights/sizes and swapped them out with em values (based on 16px=1em, true on most modern browsers, except safari, as far as i know).

here is the dashboard with firefox font minimum set to max size, without the patch: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.28.01-PM.jpg
and after: http://www.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-14-at-3.54.50-PM.jpg

Having seen some people with low vision who rely on font resizing within their browsers I'd say that some would want the text to be even larger than the first example, let alone your second example.

although switching to ems has other implications, this specific ticket deals with increasing firefox's minimum font size setting, and setting it to the maximum possible value, 24pixels. i was testing specifically against that setting.

this is different than using the browser's zoom feature. my patch doesn't yet address the horizontal issue; to fix the horizontal fit issues, the patch needs another pass with all column widths changed from hard coded pixel widths to % widths.

it looks like the left column needs to grow as well, but thats more complicated (i tried), so far i just changed all the font sizes and heights (no widths).

I think you've hit the nail on the head here - it's that the design needs to change to be able to incorporate people's requirements for wanting text to be very large. The left column may need to grow, but certainly the toolbar at the top needs to be able to stretch down to accommodate large text which may of course force items on to a second line. The Help and Screen Options links need their backgrounds to allow resizing - as do the headings for each individual widget.

I believe that those who need text to be large will accept pages looking a bit odd as long as the pages are usable.

agreed, but if the css is done correctly the look should remain good from small to huge font sizes. i think i fixed the widget headings in my latest posted version, still needs more work.

i tested this patch in latest firefox & chrome & it looks fine, in safari i got smaller text overall, but still quite usable, looks like safari is treating 1em=14px, other browsers 1em=16px; didn't check ANY ie versions to see how they behave.

IE testing is vital for patches concerning accessibility. As much as we developers hate IE, it is the browser of choice for many people with impairments as the accessibility options are good (and easier to find). Also much assistive technology including screen readers, speech recognition and screen magnifiers etc work best with IE.

yes - i'm all for ie testing, i was just commenting that ie testing because it needs to be done and i didn't fo it yet... i was mainly testing firefox with the min font size bumped up to 24px as per the ticket.

comment:12 @ocean902 years ago

  • Keywords text font zoom removed

comment:13 follow-up: @azaozz2 years ago

As far as I see only Firefox allows the users to set minimum font size and it's not meant to replace zooming. Wondering if we should concentrate on this or making zoom-in look/work better in all browsers?

comment:14 in reply to: ↑ 13 ; follow-up: @toscho2 years ago

Replying to azaozz:

As far as I see only Firefox allows the users to set minimum font size and it's not meant to replace zooming.

You can set minimum font size in Chrome and Opera too, IE being the main exception.

Wondering if we should concentrate on this or making zoom-in look/work better in all browsers?

Full zoom is different thing, it will disturb images and is often not what the user needs. And it is much easier to set a minimum font size than a default zoom per site.

I think the font size has to work, zoom would be a nice extra.

comment:15 in reply to: ↑ 14 @adamsilverstein2 years ago

Replying to toscho:

Replying to azaozz:

As far as I see only Firefox allows the users to set minimum font size and it's not meant to replace zooming.

You can set minimum font size in Chrome and Opera too, IE being the main exception.

Wondering if we should concentrate on this or making zoom-in look/work better in all browsers?

Full zoom is different thing, it will disturb images and is often not what the user needs. And it is much easier to set a minimum font size than a default zoom per site.

I think the font size has to work, zoom would be a nice extra.

interesting, i didn't even know about the minimum font size setting until seeing this ticket. thanks for your perspective

i don't think this patch effects zooming, but i didn't test for that explicitly. i would also expect the em sizings to work better on tablets, especially if we get some scaling widths as well.

comment:16 follow-up: @toscho2 years ago

On a side note: In an old plugin I set the font for the admin bar to font: menu to make sure size and font will be readable for the user. Since then the admin bar changed so often I stopped updating the plugin.

It would be nice to get that into core to avoid such an accessibility race. :)

comment:17 @SergeyBiryukov2 years ago

In big_patch.diff, replacing #wpwrap with wpwrap looks like a typo.

comment:18 @adamsilverstein2 years ago

thanks for catching that. the vertical offset still isn't quite right for the wrap div, its not tall enough when firefox min font size set at max, i will revisit when i try to address widths.

comment:19 in reply to: ↑ 16 ; follow-up: @adamsilverstein2 years ago

Replying to toscho:

On a side note: In an old plugin I set the font for the admin bar to font: menu to make sure size and font will be readable for the user. Since then the admin bar changed so often I stopped updating the plugin.

It would be nice to get that into core to avoid such an accessibility race. :)

just add font:menu to top menubar? what does this do exactly, i'm not familiar with this attribute.

comment:20 @azaozz2 years ago

The patch shouldn't change the rest of the css either, position: relative; should stay.

Last edited 2 years ago by azaozz (previous) (diff)

comment:21 in reply to: ↑ 19 @toscho2 years ago

Replying to adamsilverstein:

just add font:menu to top menubar? what does this do exactly, i'm not familiar with this attribute.

It is a shorthand for a system font, namely the fnt the user has set for the menus. Usually you have to adjust the line-hight after using that shorthand. Like this …

selector {
    font: .9em sans-serif; /* browsers without system font support */
    font: menu;            /* modern browsers */
    line-height: 1.3;      /* keep wrapped text readable */
}

@adamsilverstein2 years ago

switches fonts & heights from pixels to ems in admin, admin-bar

comment:22 @adamsilverstein2 years ago

big-font.diff cleans up a few of my changes; the interface looks much better now, at least vertically; nothing i;ve done so far affects widths.

and some screen shots, all with firefox min font size set to 24px;

posts page, before: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-10.30.40-AM.png
and after: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-10.27.24-AM.png
(note improved button & field sizes)

add category, before: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-10.30.52-AM.png
and after: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-10.27.32-AM.png
(again, better sizes for fields)

dashboard home before: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-11.00.37-AM.png
and after: http://cdn.earthbound.com/wp-content/uploads/2013/01/Screen-Shot-2013-01-20-at-10.32.02-AM.png
(note improved menu-bar height, buttons, etc.)

going to try working on the width of the left hand menu next, thats the worst looking part now.

comment:23 @togelini23 months ago

Nothing.

Last edited 23 months ago by ocean90 (previous) (diff)

comment:24 @grahamarmfield19 months ago

  • Cc graham.armfield@… added

comment:25 follow-up: @grahamarmfield19 months ago

Need to test this with the new MP6 version of trunk.

comment:26 @adamsilverstein19 months ago

  • Cc adamsilverstein@… added

comment:27 @nacin18 months ago

  • Component changed from Accessibility to Administration
  • Focuses accessibility added

comment:28 in reply to: ↑ 25 ; follow-up: @GrahamArmfield17 months ago

  • Focuses administration added

Replying to grahamarmfield:

Need to test this with the new MP6 version of trunk.

Now tested with trunk - ie 3.9 alpha, and the result is still not good.

The WCAG 2.0 guidelines contain a success criteria about this - 1.4.4 (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html). This talks (at length) about what is required, and indicates that text should be able to scale successfully without use of assistive technology to 200% of 'normal' size without compromising the readability.

As I mentioned above, it is important to remember that text resizing and zooming are not the same things, and the different approaches suit different people. Zooming does not work for some people as items on a page can become so visually separated it can be hard for people to easily deal with. All the major browsers offer text resizing as well as zooming for this reason.

I've enclosed a screenshot of the plugins page in Firefox after resizing the text up to nearly 200%. You can see that it doesn't look good.

The main problem is that some elements - like the toolbar - appear to have fixed height, so the larger than expected text just spills out, or gets hidden in the case of the form controls.

@GrahamArmfield17 months ago

Plugins page in Firefox with text nearly up to 200%

comment:29 in reply to: ↑ 28 @Volker_E.15 months ago

Replying to GrahamArmfield:

The main problem is that some elements - like the toolbar - appear to have fixed height, so the larger than expected text just spills out, or gets hidden in the case of the form controls.

Thanks @GrahamArmfield for bringing this up. As the Admin Bar is per default shown in the website's front-end, as soon as you're adjusting your site with text zoom only, you'll be confronted with menu-items spilled out over the admin bar, possibly turning unreadable.

By changing property height to min-height in rule #wpadminbar of admin-bar.css at least the problem mentioned above is fixed. Same works for many of the other elements not being rendered appropriately at text zoomed in back-end, a.o. the select elements.

@adamsilverstein8 months ago

use min-height instead of height

comment:30 @adamsilverstein8 months ago

The good new is recent css changes have made the overall admin look far better with the minimum font size setting at 24px;

Here is how it looks now:

http://cl.ly/image/2x230w0J0C3q

Here is the result of applying 12825.diff, mostly what changes is the button heights and dropdowns:

http://cl.ly/image/2F0T1E0o1p02

I left out changing the heights for the admin bar - because its abosolutely positioned, the content expects a specific height. (I did change the min-height for the admin menu dropdowns). Here is what happens:
http://cl.ly/image/2v0C1f3b1V2A

comment:31 @afercia4 weeks ago

Wondering if we should close this ticket. A similar one was closed a while ago, see #7296. I agree with the argumentation there: we can always discuss this as a part of the ongoing CSS clean up and modernization effort.

Also, I totally second @GrahamArmfield:

it is important to remember that text resizing and zooming are not the same things, and the different approaches suit different people. Zooming does not work for some people as items on a page can become so visually separated it can be hard for people to easily deal with. All the major browsers offer text resizing as well as zooming for this reason.

I'm also aware of the technical difficulties implied, relevant parts of the CSS should be refactored. Maybe it's worth considering to establish some CSS best practices for future developments. For example, fixed heights/widths and absolute positioning are real enemies for text resizing and should be avoided. Thoughts?

comment:32 @joedolson4 weeks ago

I agree. This ticket isn't practical as an action item, because it's overly broad; and there are always ongoing changes to the admin. If this happens at all, it should be handled as part of the CSS roadmap and style guide, rather than trying to retroactively fit it into the existing styles.

It's definitely not a solved problem; I'd propose setting it as 'maybelater' and paying attention to the CSS roadmap.

comment:33 @slackbot4 weeks ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

comment:34 @davidakennedy4 weeks ago

I agree with @joedolson and @afercia here. This would be a fantastic and useful change to make, but a difficult one. Our time in attacking this kind of issue is likely better spent on laying out best practices in the future, and attacking this little by little as the Admin evolves.

comment:35 @joedolson4 weeks ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.