Tabbing between links does not highlight them

Bug #367877 reported by Alan Jenkins on 2009-04-27
Affects Status Importance Assigned to Milestone
Launchpad itself
kde4libs (Ubuntu)

Bug Description

Environment: Kubuntu 9.04 Live CD
Package version: konqueror-4:4.2.2-0ubuntu4

A common method of keyboard navigation is to press the "TAB" key to move to the next link.

Technically this works, but there is no visible indicator that the link has been highlighted. This makes the feature a little difficult to use :-D.

Equally, right-clicking on a link then pressing "ESC" succeeds in selecting it, but once the context menu has gone away the link is no visibly highlighted.

By contrast, text boxes are correctly highlighted when using TAB.

Related branches

Alan Jenkins (aj504) wrote :

kdebase (konqueror) -> kdelibs (KHTML)

affects: kdebase (Ubuntu) → kdelibs (Ubuntu)
Jonathan Thomas (echidnaman) wrote :

For the record, this works for me. (At least at Google)

affects: kdelibs (Ubuntu) → kde4libs (Ubuntu)
Changed in kde4libs (Ubuntu):
importance: Undecided → Low

On Monday 27 April 2009 01:37:48 pm Jonathan Thomas wrote:
> For the record, this works for me. (At least at Google)
> ** Package changed: kdelibs (Ubuntu) => kde4libs (Ubuntu)
> ** Changed in: kde4libs (Ubuntu)
> Importance: Undecided => Low

Aha! It works for me on Google as well. It doesn't work on launchpad
though, e.g. on <>.

Jonathan Thomas (echidnaman) wrote :

Actually, it will cycle through the links, but the website doesn't give any visual feedback in Konqueror, Firefox 3.5 or any webkit based browser. (Arora, webkitkde, rekonq, etc)
I'm thinking that this is more of a website bug. ;-)

Changed in kde4libs (Ubuntu):
status: New → Invalid
Alan Jenkins (aj504) wrote :

Heh, well spotted!

I've done this before, except the other way around. I blamed Launchpad for an accessibility bug, when it was actually Konqueror's fault :-).

Thanks for going through all these bugs. It's really making me look forward to testing 9.10.

affects: launchpad → launchpad-foundations
Changed in launchpad-foundations:
importance: Undecided → Low
status: New → Triaged
tags: added: confusing-ui
Curtis Hovey (sinzui) on 2010-03-03
tags: added: css
Jonathan Lange (jml) on 2010-03-12
affects: launchpad-foundations → launchpad-web
huwshimi (huwshimi) wrote :

This is the result of 'outline' being set to 'none' in the css (in combo.css). It's common when doing a css reset to turn remove the outline on links. However, as Alan picked up, this isn't so good for accessibility. There are two ways to go about fixing this.

Option A:
Re-apply the outline after the reset. This would set a uniform style across all browsers.

Option B:
Remove the original outline reset. This would then use the browser default for active items.

I would recommend option B. This is a case where using the browser default is a good thing. Some browsers signify that an item is active with quite different styles and it's probably better to give the user the feedback that they are used to (for example, compare the way Chrome and Firefox do this). Looking at the CSS I can't see a particular reason this is being reset, and removing this shouldn't affect anything else.

I can submit a patch for this, but I just wanted to confirm this decision before I do...

Jonathan Lange (jml) wrote :

Hey Huw,

Sounds good. I think you're right in preferring Option B.


Changed in launchpad:
assignee: nobody → Huw Wilkins (huwshimi)
milestone: none → 11.02
tags: added: qa-needstesting
Changed in launchpad:
status: Triaged → Fix Committed
huwshimi (huwshimi) on 2011-01-18
tags: added: qa-ok
removed: qa-needstesting
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers