search

StackExchange / Stacks

Stack Overflow’s Design System
https://stackoverflow.design
MIT License
602 stars 90 forks source link

docs(a11y): document min viewport dimensions #1738

Closed dancormier closed 1 month ago

dancormier commented 1 month ago

STACKS-580

This PR adds a section to the Stacks docs Accessibility page describing the minimum supported viewport size, adhering to WCAG 2.2 1.4.10: Reflow.

To test

  1. Go to the new "Viewport size" section of the Stacks docs Accessibility page
  2. Let me know if it sounds reasonable and is free from grammatical/spelling errors
  3. Profit!
netlify[bot] commented 1 month ago

Deploy Preview for stacks ready!

Name Link
Latest commit 4c8a839a8a8c54c3d7db17ad410fba8fdf014569
Latest deploy log https://app.netlify.com/sites/stacks/deploys/664e557161286a0009136402
Deploy Preview https://deploy-preview-1738--stacks.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

CGuindon commented 1 month ago

Re: comment here

@giamir What's the violation you're thinking of? Not enough contrast between regular text color and link text color because we're using color alone to identify a link? I think we were hitting that issue before we switched to purple anyway (would have been a dark blue). I'd have to review full requirements here but I think this would be out of scope for this PR anyway... if there's an issue tied to a requirement do you want to open an a11y ticket?

giamir commented 1 month ago

@giamir What's the violation you're thinking of? Not enough contrast between regular text color and link text color because we're using color alone to identify a link? I think we were hitting that issue before we switched to purple anyway (would have been a dark blue). I'd have to review full requirements here but I think this would be out of scope for this PR anyway... if there's an issue tied to a requirement do you want to open an a11y ticket?

Yeah, I did not take the time to investigate further. I just had a gut feeling that somehow that the almost lack of differentiation between link text and static text probably violates something.

From WCAG SC 1.4.1 (it looks like the lack of differentiation between visited and non-visited colors won't be a problem)

Most user agents provide users with a color-only cue that a link has been previously activated by them ("visited"). However, several technical constraints result in authors having very limited control over these color-only indications of visited links. The technical constraints are as follows:

  • User agents constrain the exposure of a link's visited state due to privacy concerns. Author queries to user agents will indicate all links have not been visited.
  • Any available information on the visited state of a link would be inaccurate since it is both user and browser-dependent. Even if an author could accurately get information on previously activated links by a certain user, the author would be constrained to the current browser's preserved history, and would be unable to determine if the user had visited the page using a different browser (or if the history was not preserved, either from cache clearing or use of private sessions).
  • Authors can only use color to modify the :visited CSS pseudoclass style. The technology constrains any non-color styling. Due to palette limitations, an author cannot use color alone to achieve 3:1 contrast between link and non-link text as well as between visited and unvisited links while also achieving 4.5:1 contrast for all link and non-link text.
  • Authors also cannot set the visited state of links. The anchor element does not include a "visited" attribute; therefore the author has no ability to alter the state through an attribute setting. As such, authors cannot achieve 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value in regard to visited links.

For these reasons, setting or conveying a link's visited status is not an author responsibility. Where color alone distinguishes between visited and unvisited links, it does not result in a failure of this Success Criterion, even where the contrast between the two link colors is below 3:1. Note that authors must continue to ensure that all text links meet contrast minimums against the page background (SC 1.4.3).

There is no violation for not differentiating enough between visited and not-visited links but I believe we are still in breach of that SC since: Link underlines or some other non-color visual distinction are required (when the links are discernible to those with color vision) from https://www.w3.org/WAI/WCAG22/Techniques/failures/F73

@dancormier Could you confirm my analysis? Then I will create an a11y ticket around those lines: Link text is distinguishable from static text only via color This task will require design input @CGuindon and I suspect it won't be straightforward to come up with a solution.

dancormier commented 1 month ago

Is using a tooltip (see SC for Success Criterion) to explain an abbreviation a common pattern described somewhere in Stacks? Semantically wouldn't the abbr element be more appropriate?

You're right @giamir! abbr is the correct element here.

dancormier commented 1 month ago

@dancormier Could you confirm my analysis?

Yep, it seems you're correct and we'll need to either:

a) differentiate links (including visited ones) by some means other than color (underlining, bolding, etc), or b) differentiate significantly by both hue and lightness.

This is the particularly relevant part of WCAG SC 1.4.1 IMO:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater. For example, a light green and a dark red differ both by color (hue) and by lightness, so they would pass if the contrast ratio is at least 3:1. Similarly, if content is distinguished by inverting an element's foreground and background colors, this would pass (again, assuming that the foreground and background colors have a sufficient contrast).

purple-500 has a 1.09:1 contrast ratio between visited links and surrounding text in dark mode according to the WCAG algorithm. Bumping the base value to purple-400 still only gets us to 1.37:1.

*With all of that said, I couldn't find a single instance of a big player adhering to this rule in their respective dark modes. I checked Google, Bing, Jira, GitHub, and Reddit. Some of these sites (Jira, GitHub) didn't even have a differentiation between visited and non-visited links.

This made me second-guess my assessment that we're interpreting the requirements correctly. I reread it a few times and I can't see how else I'd interpret it. Assuming my interpretation of the rule is correct it seems like lots of sites don't hit this SC. I don't know how we want to use that information except to consider why these big sites don't bother hitting a 3:1 or providing other differentiation for links compared to adjacent text (unless I'm missing something obvious, which is very possible).

Then I will create an a11y ticket around those lines: Link text is distinguishable from static text only via color

@giamir yep, I think we need a ticket at least to investigate and consider this further.

Related question/can of worms 🐛: Considering that we use APCA to determine the contrast between text and the background, should we also use it for situations like this where we need to determine contrast between elements other than text and backgrounds where Lc 60 wouldn't apply?