act-rules.github.io
act-rules.github.io copied to clipboard
act-rules
New rule: Content triggered on hover is hoverable (ep1s13)
Rule partially checking SC 1.4.13 (the hoverable part of SC 1.4.13)
Blocked: waiting for decision on how to handle states in rules
This will require a 2 weeks Final Call (new rule)
Pull Request Etiquette
How to Review And Approve
- Go to the “Files changed” tab
- Here you will have the option to leave comments on different lines.
- Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
- Make sure to also review the proposed Final Call period. In case of disagreement, the longer period wins.
@adilsofficial and @kasperisager I've answered your comments, but I haven't made any changes to the rule. I'm looking forward to your replies, so I can decide how to proceed.
@kasperisager After spending several hours going through the event loop, I've redone the "visible changes in content" in a way that removes all assumptions. Care to have a look? :-)
Neat, I think we're getting closer! You're likely better equipped to answer this than me: Why are we only interested in events that result in animation frame callbacks? That is, event handlers may also modify the document structure directly and those changes would then become visible on the next update of the rendering, circumventing an animation frame callback. Modern frameworks do generally tend to to batch rendering operations in animation frame callbacks to maintain smooth rendering, though that's likely not the general rule.
I doubt I'm better equipped since only yesterday I started looking at this seriously! I was probably misled by step 4 of the update rendering procedure where the unnecessary rendering Documents are decided. The only objectively described condition in there relates to animation frame callbacks. Of course, there is also the condition "the user agent believes that updating the rendering of the Doc would have no visible effect" which lets all other rendering sources through. I'll try to rewrite this in a less targeted manner later today.
@kasperisager I've given another shot at the definition, this time including also step 15 of the "update the rendering" algorithm, thus, I expect, covering all rendering updates that can change the content of page (and ignoring rendering updates that do not change the content - like resize, scrolling, etc.) Looking forward to your feedback
@kasperisager With the changes requested by Wilco I've changed the applicability (to get rid of one assumption). Check to see if you're okay with that.
Summary of major changes for this revision:
- Definition of visible changes to content goes back to changes in pixels of the page (addresses https://github.com/act-rules/act-rules.github.io/pull/1396#discussion_r530323158)
- Added a condition to the applicability that the area affected by the changes must always be same every time the user hovers the element while the user does interact with other elements in the page. By asking for this consistent behaviour the causal connection between the content appearing and the hovering of the element should be established.
- Added a 5 second period before assessing changes in applicability to account for fade-in animations (addresses https://github.com/act-rules/act-rules.github.io/pull/1396#discussion_r530324906)
- Added a 1 minute period for checking if the additional content does not vanish as expectation 2 (addresses https://github.com/act-rules/act-rules.github.io/pull/1396#discussion_r530324226)
@WilcoFiers have these addressed your concerns? @kasperisager is this enough for you to ensure the connection between hovering event and content appearing on the page? @ShadowBB still waiting for your reply to https://github.com/act-rules/act-rules.github.io/pull/1396#discussion_r527113813
@WilcoFiers @kasperisager @ShadowBB This one is ready for another round of reviews. The applicability and expectations changed substantially from the previous version. Now it tries to identify content that became visible as a result of the hovering (new nodes plus nodes that change visibility) and that become invisible when the hovering ends. Expectations are that the content is adjacent to the hovered element (so that the user can move the pointer there without dismissing it) and that it does not go away for a testable amount of time (1 minute) while the pointer is at the center of the new content (once again, to ensure consistency while testing). Please, have another go at it!