Closed (fixed)
Project:
Olivero
Component:
Proof of Concept
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
14 Mar 2020 at 08:37 UTC
Updated:
29 May 2020 at 14:44 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
andrewmacpherson commentedI'm wondering if this is a regression. The class came from here #3115430: Create CSS body class that enables mobile menu at all widths. What was the skip link like at narrow breakpoints before that change was merged?
Comment #3
kostyashupenko1. Removed
utility.css2. Moved
skip-linkcomponent from utility.css toskip-link.css3. Reworked skip-link a little bit. Added
:hoverstate (underline), also--color--blue-50background was added, since sometimes we had white text above white background. On my side with high-contrast mode skip-link looks readable.Screenshots:

1. Hover state:
2. Mobile styles

Comment #4
mherchelMade a couple minor changes:
1) Changed the background color to ensure WCAG compliance (see #3119790: Insufficient contrast on the skip-link)
2) Added border, made font larger for accessibility reasons (see #3112482: Stronger focus style for skip-to-main link)
Comment #5
mherchelComment #6
mherchelCommitted!
Comment #7
mherchelComment #8
andrewmacpherson commentedThanks for working on these skip-link issues.
Re. #3.2 - I really like that mobile appearance.
Re. #4.2
What accessibility reason? The other issue didn't mention font size, because there wasn't anything wrong with that.
Patch #4:
Why use the alpha component in the border colour here? It means the border is effectively a pale blue which has a contrast ratio of just 2.3:1 versus the skip link background of blue-20, and even less against the surrounding header gradient. That's not a very strong focus indicator; there's no point in an outline which is hard to see.
I recommend removing the alpha component from the skip link border colour, and using solid white.
Comment #9
kostyashupenkoComment #10
kostyashupenkoComment #11
proeungI'm purposing a patch that changes the position of the "focus" state to relative and extending the bar across the width of the page wrapper. Let me know what you all think.
Comment #12
andrewmacpherson commented#10: this is good, fixes the low-contrast problem from #8.
#11: I think #10 is RTBC-worthy. What's the thinking behind the design in #11?
Comment #13
andrewmacpherson commentedWhen the toolbar (module) is shown for a ligged-in user, the skip-link doesn't appear. It's positioned at the top of the viewport, and is obscured by the toolbar.
Bartik, Seven, Umami (via Classy?) take this into account when positioning it.
Comment #14
mherchelThat's a good catch.
@proeung I've fixed some similar issues at https://git.drupalcode.org/project/olivero/-/blob/8.x-1.x-dev/css/src/co..., where you can make use of the same styles.
Note you'll not want to use the
var(--sp4)or:not(.is-always-mobile-nav)Comment #15
kostyashupenkoComment #16
kostyashupenkoReroll, also about:
This issue related to toolbar.js Cause of it is wrong
padding-topcalculation value when toolbar exist (it happens on my side only on page-load), so i guess it is https://www.drupal.org/project/drupal/issues/2958478), we don't need to fix it here. For now after page was loaded you can just click on any toolbar-tab, then calculation ofpadding-topforbodywill be adapted and all will be fine with skip-link.Btw this bug happens on my side only on
user/pages. For example onnode/#all fine by default. Anyway :)Comment #17
kostyashupenkoThis is how it looks currently on my side:

Well, maybe make sense to show skip-link above toolbar? Idk :)
Comment #18
brianperryReviewed and tested the latest patch and the skip link functions correctly and the styles appear consistent.
I was unable to duplicate the issues with the skip link being obscured by the admin toolbar for some reason. Based on the fact that there is a related core issue for this that could solve this problem, I've created https://www.drupal.org/project/olivero/issues/3133458 to track the toolbar issue specifically. Helping the core issue through would be ideal. If we do have to make specific fixes in Olivero, I'd imagine they would have to be adjusted once the root cause is solved.
Assuming that the admin toolbar overlap is no longer part of this issue, marking it RTBC.
Comment #19
proeungI committed the patch that @kostyashupenko (#16) submitted as it's good enough to be included in our Alpha release. If there are additional feedback and bug found related to the admin toolbar, let's open a follow-up ticket on this.
@brianperry Thanks for reviewing and testing this patch!