Update/skipto smooth scrollto element highlightling

[jongund]

---

WAI Preview Link (Last built on Thu, 17 Oct 2024 00:09:21 GMT).

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed New Skipto Scroll Preview Options.

The full IRC log of that discussion

<jugglinmike> TOPIC: New Skipto Scroll Preview Options
<jugglinmike> Matt_King: MY UNDERSTANDING IS THAT JON'S WORK CONCERNS THE VISUAL INDICATION OF WHERE FOCUS WILL MOVE UPON SELECTION OF A PARTICULAR OPTION
<Adam_Page> q+ TO SUGGEST A FOURTH OPTION
<jugglinmike> Matt_King: IT WOULD BE GREAT IF FOLKS WHO CAN REVIEW THE VISUALS CAN TAKE A LOOK
<jugglinmike> Matt_King: DO WE MAKE NO CHANGE, CHOOSE THE SMOOTH-SCROLLING OPTION, OR CHOOSE THE INSTANT-SCROLLING OPTION?
<jugglinmike> ack Adam_Page
<Zakim> Adam_Page, you wanted to SUGGEST A FOURTH OPTION
<jugglinmike> Adam_Page: I'D LIKE TO CONSIDER USING BOTH KINDS OF SCROLLING BUT WE GATE THE SMOOTH SCROLLING ACCORDING TO THE "uses smooth scrolling" MEDIA QUERY
<lola> +1 to Adam's suggestion
<jugglinmike> Adam_Page: WE COULD GIVE APG USERS APG A NICE EXPERIENCE ACCORDING TO THEIR OWN PREFERENCE AND ALSO DEMONSTRATE A BEST-PRACTICE
<jugglinmike> Matt_King: BOTH OF THESE ARE GATED BASED ON THAT SETTING. IT SOUNDS LIKE YOU ARE THINKING THAT ONLY THE "SMOOTH SCROLLING" OPTION SHOULD BE, THOUGH
<jugglinmike> Matt_King: MAKE "SMOOTH SCROLLING" THE DEFAULT, BUT IF YOU HAVE "reduced animation" ENABLED, REVERT TO "INSTANT SCROLLING"
<siri> Can you share the link?
<jugglinmike> lola: THE SMOOTH SCROLLING OPTION IS AVAILABLE FOR REVIEW HERE https://deploy-preview-366--aria-practices.netlify.app/aria/apg/
<jugglinmike> lola: THE INSTANT SCROLLING OPTION IS AVAILABLE FOR REVIEW HERE https://deploy-preview-364--aria-practices.netlify.app/aria/apg/
<jugglinmike> Adam_Page: I MISUNDERSTOOD WHAT WE WERE DISCUSSION. I DIDN'T UNDERSTAND THAT THIS IS A "PREVIEW" EFFECT
<jugglinmike> Matt_King: AS FAR AS I KNOW, WHEN YOU ACTIVATE THE ITEM, THE SCROLLING IS ALWAYS INSTANTANEOUS
<jugglinmike> lola: I CAN DEFINITELY UNDERSTAND WHY THIS SHOULD BE GATED BY REDUCED MOTION. THE "SMOOTH SCROLLING" OPTION WOULD DISORIENT ME IF I WERE TO USE IT REGULARLY
<jugglinmike> lola: IF I'M HONEST, I DO PREFER THE "INSTANT SCROLLING" OPTION WITHOUT THE "SMOOTH SCROLLING" AT ALL
<jugglinmike> CurtBellew: I ALWAYS PREFER A SMOOTH SCROLL BECAUSE FOR ME, I TEND TO LOSE CONTEXT ABOUT WHERE I AM WHEN THE SCROLL POSITION "JUMPS"
<jugglinmike> siri: I WOULD LEAN TOWARDS Adam_Page'S ORIGINAL SUGGESTION
<jugglinmike> Adam_Page: I FEEL LIKE THERE IS NUANCE IN THIS CASE BECAUSE I THINK MANY USERS WOULD NOT EXPECT THAT WE SHOW A PREVIEW; THEY WOULD EXPECT THE PAGE ONLY TO RESPOND WHEN THEY ACTUALLY ACTIVATE THE BOTTOM
<jugglinmike> Adam_Page: USERS LIKE lola MIGHT NOT HAVE THE "reduced motion" SETTING ENABLED BECAUSE THEY GENERALLY AREN'T SENSITIVE, BUT THAT THEY WOULD STILL FIND THIS PARTICULARLY BEHAVIOR DISORIENTING
<jugglinmike> lola: I REMEMBER THAT WE DON'T WANT TO INTRODUCE SETTINGS ON APG FOR A NUMBER OF REASONS, BUT PERHAPS WE HAVE A TOGGLE ON THE PAGE; THAT COULD BE OVERKILL, THOUGH.
<jugglinmike> Matt_King: WITHOUT ANY PERSISTENCE, I DON'T THINK A TOGGLE FOR THIS BEHAVIOR WOULD BE VERY HELPFUL
<jugglinmike> Adam_Page: MAKING IT SLOWER MIGHT MAKE THIS MORE AGREEABLE TO MORE FOLKS. A CHANGE LIKE THAT SHOULD BE EASY TO IMPLEMENT TECHNICALLY
<lola> q+
<jugglinmike> Adam_Page: I THINK THIS IS NOVEL, AND I THINK THERE'S A VALUE IN PRESENTED A UI TO SIGHTED USERS WHICH GIVE THEM SOME ADVANTAGE OF THE HEADING HIERARCHY. ORIENTING THEM SPATIALLY ON THE PAGE ALSO SEEMS VALUABLE
<jugglinmike> CurtBellew: I ALSO APPRECIATE THE SMOOTH SCROLLING BECAUSE, AS I MENTIONED, IT HELPS ME UNDERSTAND WHAT'S HAPPENING
<Adam_Page> q+ TO NOTE AN UNRELATED QUIRK IN THE DESIGN
<jugglinmike> jugglinmike: THIS ALMOST FEELS MORE LIKE A BROWSER FEATURE THAN A WEB APP FEATURE. USERS WHO APPRECIATE THIS WOULD PROBABLY PREFER IT IMPLEMENTED CONSISTENTLY ACROSS ALL DOCUMENT-FRAGMENT LINKS THAT THEY ENCOUNTER ON THE WEB AT LARGE
<jugglinmike> CurtBellew: THERE ARE WEB EXTENSIONS THAT IMPLEMENT THIS KIND OF BEHAVIOR
<jugglinmike> Matt_King: IMPLEMENTING IT HERE COULD BE A FIRST STEP IN A JOURNEY TOWARD GETTING IT IMPLEMENTED MORE WIDELY
<jugglinmike> ACK lola
<jugglinmike> lola: WOULD SLOWING DOWN THE ANIMATION IMPACT THE USEFULNESS TO YOU, CurtBellew?
<jugglinmike> CurtBellew: NOT AT ALL
<jugglinmike> ACK Adam_Page
<Zakim> Adam_Page, you wanted to NOTE AN UNRELATED QUIRK IN THE DESIGN
<jugglinmike> Adam_Page: IN THE DESIGN OF THE MENU ITSELF--THE VISIBLE UI FOR IT--EACH HEADING IN THE HEADING SECTION IS PRECEDED BY THE HEADING LEVEL WITHIN A SET OF PARENTHESIS
<jugglinmike> Adam_Page: THERE WAS A LITTLE BIT OF COGNITIVE FRICTION TO UNDERSTAND THAT
<jugglinmike> Adam_Page: I DON'T THINK IT'S SOMETHING WE NECESSARILY HAVE TO ADDRESS NOW, BUT I WANTED TO NOTE IT AT LEAST
<jugglinmike> Matt_King: IF IT INCLUDED THE WORD "LEVEL", WOULD THAT HELP?
<jugglinmike> Adam_Page: I THINK SO, THOUGH THAT MIGHT BE VERBOSE
<jugglinmike> Adam_Page: TO ME, THE VISUAL INDENTATION COMMUNICATES THE HIERARCHY IN A MORE SUBTLE WAY
<jugglinmike> Matt_King: SO YOU'RE SUGGESTING TO ONLY PROVIDED THE LEVEL INFORMATION TO SCREEN READERS BECAUSE THE VISUAL INDENTATION IS SUFFICIENT FOR THOSE WHO CAN OBSERVE IT
<jugglinmike> Adam_Page: THAT'S RIGHT
<jugglinmike> github: https://github.com//pull/3147

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed New Skipto Scroll Preview Options.

The full IRC log of that discussion

<Jem> Topic: New Skipto Scroll Preview Options
<Jem> feedback is available from https://github.com//pull/3147#issuecomment-2429994345
<Jem> github:https://github.com//pull/3147
<Jem> one of the feedback was to slow down the motion
<Jem> ..with option
<Jem> reduce motion is not getting any scroll.
<Jem> reduce/jon:reduced/
<Jem> adam: I am skeptical to add the skip to everywhere in the hilton site but it can be super useful.
<Jem> ...navigating the screen will turn off the scroll option.
<Jem> three options - 1. no scroll at all
<Jem> 2. smooth scroll only
<Jem> Jon: changing the scroll timing will be difficult. the browser controls the time.
<Jem> ..I can look into the way to change the scroll time in CSS.
<Jem> adam: you are right, jon. once you do set up in js, the browser will take care of the rest of timing
<Jem> arie: agreed
<Matt_King> I think there could be 4 options for the skipTo script:
<Matt_King> 1. never scroll
<Matt_King> 2. Instant scroll only, no scroll if reduced motion.
<Matt_King> 3. smooth scroll only, no scroll if reduced motion.
<Matt_King> 4. smooth default, instant scroll if reduced motion
<Jem> Adam: the scroll that happened before I activated the link. It was a surprise, although I am not motion-sensitive.
<Jem> jon: I am thinking how much effort I should add to this..
<Jem> adam: I see the value of the skip to and the browser implemented this decade ago. There are some cases which is super helpful like in wikipedia - long page but some of the commercial site may not need those because it is short.
<Jem> and marketing focused.
<Jem> Jon: I got feedback that smooth is worst or instant scrolling is more receptive to the group of people I talked to.
<Jem> jon: there is also the browser version.
<jongund> https://skipto-landmarks-headings.github.io/page-script-5/browsers.html
<Jem> curt: we also use some skip to feature to some of our site, but not for all.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed PR 3147 - SkipTo Scroll feature.

The full IRC log of that discussion

<jugglinmike> Topic: PR 3147 - SkipTo Scroll feature
<jugglinmike> github: https://github.com//pull/3147
<jugglinmike> Matt_King: jongund asked for this to be back on the agenda
<jugglinmike> Matt_King: This is the pull request for the "skipTo" feature that has smooth scrolling
<jugglinmike> Matt_King: In our prior discussions, it seemed like there really wasn't a consensus around whether we even wanted to add this feature (whether it be smooth scrolling or instant scrolling)
<jugglinmike> Matt_King: I thought the decision was to leave it the way it is for now, but jongund, it sounded like maybe you were having second thoughts and thought we should choose one of the scrolling options.
<jugglinmike> jongund: The more I thought about it--since it does support "reduced motion" media query, we allow folks to opt out depending on their system configuration
<jugglinmike> jongund: I thought it was something that some people in the group thought was valuable
<jugglinmike> jongund: I like that if someone discovers it and uses it (especially on a touch device or something like that), it actually shows you where you're going to go
<jugglinmike> jongund: Part of my view of skipTo is that it's like a curb-cut. Maybe it's there because it's required by law, but people find other uses for it
<jugglinmike> jongund: Right now, I think "skipTo" is included only because it is understood as a vague requirement. I see "skipTo" as being more than just meeting an accessibility requirement. It also raises awareness of concepts like headings and landmarks to people who may not have thought about them before. That's the bigger picture for me
<jugglinmike> Matt_King: I think that making a change right now to just add this one particular feature to "skipTo", we would need a decision about which to do--instant or smooth
<jugglinmike> Matt_King: I think people liked the smooth scrolling more, but thought it was a little too fast. You said that it may have been difficult to slow down.
<jugglinmike> Matt_King: Also, there are even fewer people available on the call today
<jugglinmike> Matt_King: Years ago, you mentioned the option of having the "skipTo" menu always visible. That's a template change. Back when we were working on the redesign, Shawn seemed amenable to that idea, but it got de-prioritized because we had so much on our plates
<jugglinmike> Matt_King: Currently, though, "skipTo" is different on APG as it is on the rest of WAI
<jugglinmike> s/you mentioned/jongund mentioned/
<jugglinmike> Matt_King: On the rest of WAI, I see there is a "skip to content" link. It just goes to "main"
<jugglinmike> jongund: That's a traditional "skipTo" link. It worked for the past 24 years; it will probably work for another 24 years
<jugglinmike> Matt_King: Do you think that the WAI team would be interested in upgrading its skipTo functionality, dmontalvo?
<jugglinmike> dmontalvo: There's an issue that Kevin opened about the skipTo keyboard interaction. It was flagged by someone that you cannot use the "tab" key throughout the interaction. That infringed WCAG
<jugglinmike> Matt_King: It supports arrow key navigation exclusively because it's a menu. You are supposed to "tab" out of a menu, so it would be incorrect to interpret that key differently
<jugglinmike> dmontalvo: That's true from an ARIA perspective, but I think the user expectation may be different
<jugglinmike> Matt_King: I'm happy to discuss. I just don't know why we would want to break keyboard conventions. We certainly want to follow our own guidance
<jugglinmike> Matt_King: The primary thing here is making the button always visible (whether it's a link or a button)
<jugglinmike> Matt_King: I think we did have a design for a non-very-obtrusive (but still visible) element for "skip to"
<jugglinmike> Matt_King: I think Isaac originally worked on it, we could probably find it
<jugglinmike> jongund: The default behavior is for it to be constantly visible; we configured it otherwise via an HTML "data-" attribute
<jugglinmike> Matt_King: So it would be a matter of how we style and position it
<dmontalvo> https://github.com//issues/3111
<dmontalvo> This issue was closed
<jugglinmike> dmontalvo: We can re-open the issue, but we'll definitely want to have a conversation
<jugglinmike> Matt_King: This is not a burning issue, clearly--not something we have to solve on a rapid time-table. But it seems like it could potentially be a win for a lot of groups (if we were to make it more visible, that is)