WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 6 days ago

#12825 new defect (bug)

Largest minimum text size in FF prefs makes admin display terrible

Reported by: jane Owned by:
Milestone: Future Release 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 (3)

big_patch.diff (22.9 KB) - added by adamsilverstein 15 months ago.
big-font.diff (25.3 KB) - added by adamsilverstein 15 months 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 2 months ago.
Plugins page in Firefox with text nearly up to 200%

Download all attachments as: .zip

Change History (32)

comment:1 designsimply4 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 designsimply4 years ago

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

comment:3 azaozz4 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: toscho4 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: azaozz4 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 toscho4 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 nacin3 years ago

  • Milestone changed from Awaiting Triage to Future Release

comment:8 grahamarmfield21 months 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.

adamsilverstein15 months ago

comment:9 follow-up: adamsilverstein15 months 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: grahamarmfield15 months 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 adamsilverstein15 months 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 ocean9015 months ago

  • Keywords text font zoom removed

comment:13 follow-up: azaozz15 months 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: toscho15 months 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 adamsilverstein15 months 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: toscho15 months 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 SergeyBiryukov15 months ago

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

comment:18 adamsilverstein15 months 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: adamsilverstein15 months 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 azaozz15 months ago

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

Last edited 15 months ago by azaozz (previous) (diff)

comment:21 in reply to: ↑ 19 toscho15 months 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 */
}

adamsilverstein15 months ago

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

comment:22 adamsilverstein15 months 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 togelini8 months ago

yg ini satu lagi buat refrensi anda mungkin dapat dijadikan artikulasi ​http://bekatak.com disana dapat anda lihat cucak rowonya....

Version 0, edited 8 months ago by togelini (next)

comment:24 grahamarmfield4 months ago

  • Cc graham.armfield@… added

comment:25 follow-up: grahamarmfield4 months ago

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

comment:26 adamsilverstein4 months ago

  • Cc adamsilverstein@… added

comment:27 nacin3 months ago

  • Component changed from Accessibility to Administration
  • Focuses accessibility added

comment:28 in reply to: ↑ 25 ; follow-up: GrahamArmfield2 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.

GrahamArmfield2 months ago

Plugins page in Firefox with text nearly up to 200%

comment:29 in reply to: ↑ 28 Volker_E.6 days 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.

Note: See TracTickets for help on using tickets.