#12825 closed defect (bug) (maybelater)
Largest minimum text size in FF prefs makes admin display terrible
Reported by: |
|
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)
Change History (40)
#2
@
15 years ago
Here is another screenshot illustrating this problem from a WordPress.com user:
http://img.skitch.com/20100504-9iyh8wmhd4fcg6gnmx3g82845.png
#3
@
15 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.
#4
follow-up:
↓ 5
@
15 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.
#5
in reply to:
↑ 4
;
follow-up:
↓ 6
@
15 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.
#6
in reply to:
↑ 5
@
15 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.
#8
@
13 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.
#9
follow-up:
↓ 10
@
12 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.
#10
in reply to:
↑ 9
;
follow-up:
↓ 11
@
12 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.
#11
in reply to:
↑ 10
@
12 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.
#13
follow-up:
↓ 14
@
12 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?
#14
in reply to:
↑ 13
;
follow-up:
↓ 15
@
12 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.
#15
in reply to:
↑ 14
@
12 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.
#16
follow-up:
↓ 19
@
12 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. :)
#17
@
12 years ago
In big_patch.diff, replacing #wpwrap
with wpwrap
looks like a typo.
#18
@
12 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.
#19
in reply to:
↑ 16
;
follow-up:
↓ 21
@
12 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.
#20
@
12 years ago
The patch shouldn't change the rest of the css either, position: relative;
should stay.
#21
in reply to:
↑ 19
@
12 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 */ }
#22
@
12 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.
#27
@
11 years ago
- Component changed from Accessibility to Administration
- Focuses accessibility added
#28
in reply to:
↑ 25
;
follow-up:
↓ 29
@
11 years 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.
#29
in reply to:
↑ 28
@
11 years 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.
#30
@
10 years 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
#31
@
10 years 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?
#32
@
10 years 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.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
10 years ago
#34
@
10 years 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.
#35
@
10 years ago
- Milestone Future Release deleted
- Resolution set to maybelater
- Status changed from new to closed
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