Closed Bug 63962 Opened 24 years ago Closed 14 years ago

Focused appearance prefs are not exposed

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: bugs4hj, Assigned: marlon.bishop)

References

(Blocks 1 open bug)

Details

(Keywords: access) 

After tabbing trough a document the focused items are very bad to recognize.
Only a small dotted line around the text can be seen, but even this doesn't work
everywhere. As a work around I use :focus { border : 2px solid black }  for our
own websites, but for other website's this doesn't work and then it's hard to
see where you are!

Can't this go into preferences?

n.b. Selecting your own style sheet improves the support for visually disabled
people!
bug 63963 is a duplicate of this bug
*** Bug 63963 has been marked as a duplicate of this bug. ***
so, you want to have something that is more visible, like a darker border default?
IE 5 for Mac and Opera 5 have more conspicuous focus rings. Some authors complain 
about those. (Artistic vision etc...)

See also bug 53927.
Yes Doron, please, for visual disabled people this is a must have.

Take the test:
Take a look at your monitor. Close your eyes a bit (untill the moment where you
are almost inable to read the characters on your screen) That's exactly what
visual disabled people see, almost nothing! A white fog. And even by taking a
larger font, they are still unable to see the small dotted line.

And are you familiar with Access-Board Section 508? Why improved governmental
websites, if user agents are unable to provide the functionality to support
this? A logical action is to inform/warn a site visitor that the used browser
doesn't 'fully' support Section 508. Why?? Lack of support for custom navigation
tools. (OBJECT/USEMAP/TABINDEX and so one) Those items are now marked 'future'.

Henri: Web authors should pay more attention. 
Even for us people with "good" eyesight it is hard to see. I am going to go
ahead and mark NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
making an rfe and over to html element
Assignee: asa → clayton
Severity: normal → enhancement
Component: Browser-General → HTML Element
Keywords: helpwanted
QA Contact: doronr → lorca
Summary: Focused items in documents are bad to recognize → [rfe] Focused items in documents are bad to recognize
We should ship an alternative stylesheet for the visually impaired
Severity: enhancement → normal
Component: HTML Element → Browser-General
Keywords: helpwanted
QA Contact: lorca → doronr
Summary: [rfe] Focused items in documents are bad to recognize → Focused items in documents are bad to recognize
hixie should this land in style system or html element or elsewhere?
Assignee: clayton → pierre
Severity: normal → enhancement
Component: Browser-General → Style System
QA Contact: doronr → chrisd
Summary: Focused items in documents are bad to recognize → [rfe] Focused items in documents are bad to recognize
Summary: [rfe] Focused items in documents are bad to recognize → [rfe] Focused items in documents are hard to recognize
Depends how we fix it. At the moment there isn't much we can do. Possible fixes
are to properly support 'outline', or do XBL form controls.

An earlier attempt at making the outline was shot down and that is why we are 
using the current scheme. (Web designers don't want _any_ :focus outline, it
seems.) Is what we are doing any different to what IE does, out of interest?
Ian, why do you think W3C changed !important??
Is that because of visually impaired surfers?
And ask yourself, should web authors say no to the visually impaired?
And I would like to be social, you agree with that?

IE5 - comparing to ie, the dotted line is pretty much the same, except: links
chnage color if they are tabbed to, and form elements get the shown text
highlighted as if they were selected via the mouse.

this does help visablity.	

H-J: I am not stating personal views. Reread what I said. I am merely stating 
facts. If we want Mozilla to be used then web authors must support it and web
surfers must like it. Increasing the focus size did neither of those. People 
with special needs should use distributions that have optimised their html.css
files for them.

Doron: Thanks... We can help with the first of those; I'm not sure what you mean
by the second. Could you give me an example? Cheers!
Note for Ian:  sorry but I consider that last statement a personal view only!

P.s. I'm NOT visually impaired, but working on Access-Board Section 508.

This is a good example of how doing something for accessibility helps anyone.
I have 20/20 vision and there have been times where I can't find the focus.
Is it possible now to change the look of the focussed selected text with a
stylesheet change? I think it isn't - although it should be. The W3C's user
agent guidelines ask for it, and the team looking at accessibility has this on
the growing list of requirements as well.
yes, it is, 
   :focus { -moz-outline: 5px dotted WindowText; } 
...for example.
If you know how, you can make changes to the default style sheet of Mozilla. So
how hard is it to get something like this into preferences? Lets take this
example: we have a houshold with 6 people.

As a test we now use both border and changed background color.First of all.
If you know CSS, you can make changes to the default style sheet. But what does
it take to get something like this into preferences? Select your own style
sheet, without tricks.

Lets take this example: an household with 6 people, and only one is having
difficulties with his/her visibility. All of them are using the same computer
system to access the Internet, and they are all using the same User Agent.
Wouldn't it be nice to have an profile with a default selected style sheet
attache to it? I also like to have a simple way to select a custom style sheet,
while visiting a site. In case a style sheet doesn't seems to work for that
site. In Opera it's very easy to select an custom style sheet.

We now advise web authors to set focused items to:

:focus { border : 1px dotted WindowText;
background-color : #xxxxxx; }

Using this technique you get a clearer view on focused items. We hope to support
visually impaired visitors by doing this. If you know a better way... just tell me!

Did you know that more then 20% of the US nation (54 million)  have a kind of
disability!! And only 1.2% is working for the government. And did you know that
this 20% is growing by the day?? Calculate your changes on getting a disability!
One out of five!! I sure hope not, but the fact's are very strict in this case!
It's only seems a matter of time!

I added the line :focus { -moz-outline: 3px dotted WindowText !important;}
to userChrome.css in my profile's chrome directory
There were two problems with this:
1. The big dots got in the way of text and made the text much less visible.
2. It doesn't work on buttons


:focus {background-color: black !important;
        color: white !important;
        font-weight:bold !important;
        }

That works pretty well - I can see the focus changes very easily.
However, buttons are again somewhat of a problem in that they aren't affected by
the font-weight. Why aren't buttons responding to my .css?

"Doron: Thanks... We can help with the first of those; I'm not sure what you mean
by the second. Could you give me an example? Cheers!"

hixie: example is in say resolved bug on this page, if you want to select a
resolution, you get a drop down and can select one. Now, in ie, if i tab to this
dropdown, the element showing gets a blue background (as if you were selecting it).

I can take a screenshot if it helps ;)
Aaron, and increasing the line height, would that be of any help to you?
One thing that's nice about I.E. is that it reverses the color where the dotted
lines go, so you can still see the focus if you have a dark background.
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
These focus prefs are now implemented:

SetBoolPref("browser.display.use_focus_colors", useFocusColors);
SetCharPref("browser.display.focus_background_color", colorString);
SetCharPref("browser.display.focus_text_color", colorString);
SetCharPref("browser.display.focus_ring_width", numPixels); /* 0-4 */

These prefs can now be part of the publicly visible appearance preferences panel.

Over to German for comment and reassignment.
Assignee: pierre → german
Keywords: access
Summary: [rfe] Focused items in documents are hard to recognize → [rfe] Focused appearance prefs are not exposed
Blocks: uaag
reassigning.
Assignee: german → dbaron
Based on comment 24, the remaining issues in this bug are for the Prefs frontend
implementation.  Changing component to Preferences and reassigning.
Assignee: dbaron → sgehani
Component: Style System → Preferences
QA Contact: ian → sairuh
Over to Marlon for input on exposing these prefs.
Assignee: sgehani → marlon
See also bug 32818, pref to disable link outlines (wontfix).
We should implement 'outline' correctly, remove the hidden prefs, and use
userContent.css to handle this.

However, that's another bug.

Regarding this bug, I believe that having GUI prefs for this is an overkill. A
distribution designed for disabled users would have to change a lot more than
just the focus outlines, and thus it would not be a big deal to either change
this in prefs.js or add the panel to the prefs. That could even be made an XPI.

I propose we WONTFIX this for the Mozilla trunk. Comments?
I'd disagree that users with moderate vision impairments (which this bug is
aimed at) should require a completely separate browser. However, I agree that
this RFE should be wontfixed. We should just fix the bugs (use outline instead
of border, use white dots instead of black ones if the background is dark, and
use Mac-style focus rings on Mac OS), not add prefs to work around them.
Why wontfix this? There are already pref settings for link colors, so why not
another one for this issue? Why is it this hard to implement something good for
other people who really need it? How can you even say no to them if you don't
really know what the problem is? Do you have family members with this sort of
problems too? Then please ask _them_ what they need, don't tell them what _you_
think is best for them! Please pay respect to other less blessed people.

Remember, I don't need this for myself, but other people really need it.
I would like to do something like this for accessiblity. The thin dotted outline
is very, very difficult to see. The average user may not need this, but that
isn't the point. At some point we may need to have a separate accessibility
prefs panel for important accessibility things like this.

Other than using a thick border, another way to make the focus easy to see is to
change the background and text color. This is extremely effective. A possible
pref could be a checkbox, saying "Use high contrast focus".


aaron: we should always use high contrast focus. Hence we don't need to make
this a pref.
Ian, do you mean that other Mozilla and Netscape people will accept having the
background and forgeground color of the currently focused item change?

Perhaps they would, I hadn't considered that. I wonder if that would make us too
different from IE for people's taste. Would be nice though, to easily see where
you're navigating to.
Oh, I see what you mean. I thought you meant high-contrast outlines, my bad.

Yes, I think a single preference with the Colours preferences (possible
replacing the underlined links prefs?) would not be a bad idea considering the
potential gains. We would have to make sure this remained a single preference
though.

I'm no expert, maybe mpt has thoughts on how the colour/fonts/appearance prefs
should work?
Summary: [rfe] Focused appearance prefs are not exposed → Focused appearance prefs are not exposed
Product: Browser → Seamonkey
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.