From fe273e4bfa9a011ad8d8acb931e531be07138d32 Mon Sep 17 00:00:00 2001 From: Rohan Kumar Date: Fri, 21 Oct 2022 16:49:59 -0700 Subject: [PATCH] Re-phrase most of the site design guidelines Since this page lists requirements, I adopted a stricter writing style --- content/meta/site-design.md | 161 ++++++++++++++++++++++-------------- 1 file changed, 99 insertions(+), 62 deletions(-) diff --git a/content/meta/site-design.md b/content/meta/site-design.md index ef70d53..10c61ef 100644 --- a/content/meta/site-design.md +++ b/content/meta/site-design.md @@ -5,54 +5,62 @@ title: Site design standards description: "The accessibility statement and design standards I hold myself to when creating seirdy.one" date: "2022-06-10T00:00:00+00:00" --- -This site may look simple on the surface, but I put a _lot_ of thought into it. I hold myself to a long list of requirements concerning accessibility, compatibility, privacy, security, and machine-friendliness. +This site may look bare-bones on the surface, but I put much thought into it. I hold myself to a long list of requirements. I make mistakes; if part of my site violates these standards, please contact me! -

Note: all references to "pixels" (px) in this section refer to CSS pixels.

+

Note: all references to "pixels" (px) refer to CSS pixels.

+ +{{}} Accessibility statement ----------------------- -I've made every effort to make seirdy.one as accessible as possible. More information about the accessibility-related work for seirdy.one is in my post {{}}{{}}{{}}. +I hold seirdy.one to the highest accessibility standards possible. For more information about seirdy.one's accessibility-related work, read {{}}{{}}{{}}. ### Conformance status -The [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. I've made sure seirdy.one is **fully conformant with WCAG 2.2 level AA.** +The [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. I make seirdy.one **fully conformant with WCAG 2.2 level AA.** -Fully conformant means that the content fully conforms to the accessibility standard without any exceptions. +Fully conformant means that the content conforms to the accessibility standard without any exceptions. -### Additional accessibility considerations +### More accessibility considerations -Additionally, I strive to conform to WCAG 2.2 level AAA wherever applicable. I comply with all AAA criteria except for the following: +I conform to all WCAG AAA success criteria (SC) _except_ the following: -SC 2.4.9 Link Purpose (Link Only) -: I'm actually trying to follow this criterion, but it's a work in progress. Let me know if any link names can be improved! Link purpose _in context_ always makes sense. +SC 2.4.9 Link Purpose (Link Only) +: SC 2.4.9 conformance is a work in progress. Let me know if any link names need improvement! Link purpose _in context_ always makes sense. -SC 3.1.5 Reading Level -: The required reading ability often exceeds the lower secondary education level, especially on more technical articles. +SC 3.1.5 Reading Level +: Required reading ability often exceeds the lower secondary education level. -SC 3.1.6 Pronunciation -: I do not yet provide any pronunciation information. +SC 3.1.6 Pronunciation +: I do not currently offer any pronunciation information. -I have only tested WCAG compliance in mainstream browser engines (Blink, Gecko, WebKit). Full details on how I meet every WCAG success criterion are on a separate page: [Details on WCAG 2.2 conformance](../wcag-conformance/) +I have only tested WCAG compliance in mainstream browser engines (Blink, Gecko, WebKit). For full details on how I meet every WCAG success criterion, read [Details on WCAG 2.2 conformance]({{}}). -I also go further than WCAG in many aspects: +The WCAG presents a starting point, not a stopping point. Here are some non-WCAG accessibility criteria I consider: -- Rather than follow SC 2.5.5's requirement to achieve a minimum tap target size of 44 by 44 pixels, I follow Google's more strict guidelines. These guidelines mandate that targets are at least 48-by-48 pixels, with no overlap against any other targets in a 56-by-56 pixel range. I try to follow this guideline for any interactive element that isn't a hyperlink surrounded by body text. +- Rather than follow SC 2.5.5's advice to achieve a minimum tap target size of 44 by 44 pixels, I follow Google's more strict guidelines. These guidelines mandate target sizes of at least 48-by-48 pixels, with no overlap against any other targets in a 56-by-56 pixel range. I follow this guideline for any interactive element _except_ inline hyperlinks surrounded by non-interactive text. -- I ensure at least one such 56-by-56 px non-interactive region exists on the page, for users with hand tremors or or anyone who wants to tap the screen without clicking something. +- I ensure at least one such 56-by-56 px non-interactive region exists on the page, for users with hand tremors or anyone who wants to tap the screen without clicking something. -- With the exception of in-text borders, I only set custom colors in response to the `prefers-color-scheme: dark` media query. These custom colors pass APCA contrast ratios, all being close to the ideal lightness contrast of 90. They are also autism- and overstimulation-friendly colors: the yellow links are significantly de-saturated to reduce harshness. +- Except for text borders, I only set custom colors in response to the `prefers-color-scheme: dark` media query. These custom colors have an Advanced Perceptual Contrast Algorithm (APCA) lightness contrast close to the ideal value of 90. I use autism- and overstimulation-friendly colors: the yellow links have low saturation to reduce harshness. -- I ensure that the page works on extremely narrow viewports without triggering two-dimensional scaling. It should work at widths well below 200 CSS pixels. +- I ensure narrow viewports don't cause two-dimensional scrolling. I test this at widths narrower than 200 CSS pixels; this is much stricter than the WCAG threshold values. ### Assessment and evaluation -I test each WCAG success criterion myself using the mainstream browser engines (Blink, Gecko, WebKit). I test using multiple screen readers: Orca (primary, with Firefox and Epiphany), NVDA (with Firefox and Chromium), Windows Narrator (with Microsoft Edge), Apple VoiceOver (with desktop and mobile Safari), and Android TalkBack (with Chromium). +I test each WCAG success criterion with the mainstream browser engines: Blink, Gecko, and WebKit. I test using multiple screen readers: -I also accept user feedback. Users are free to contact me through any means linked on my [About page](../../about/). +- Orca (primary, with Firefox and Epiphany) +- NVDA (with Firefox and Chromium) +- Windows Narrator (with Microsoft Edge) +- Apple VoiceOver (with desktop and mobile Safari) +- Android TalkBack (with Chromium) -Finally, I supplement manual testing with the following automated tools: +I also accept user feedback. Feel free to contact me through any means linked on my [About page]({{}}). + +The following automated tools supplement manual testing: - [axe-core](https://github.com/dequelabs/axe-core) - [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/toolkit/verify/automated) @@ -62,45 +70,47 @@ Finally, I supplement manual testing with the following automated tools: - [webhint](https://webhint.io/) - [lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) -WAVE reports no errors; AXE is unable to determine certain contrast errors, but it otherwise reports no errors; IBM Equal Access reports no errors but some items that need review. +WAVE reports no errors. AXE sometimes fails to measure contrast, but otherwise reports no errors. IBM Equal Access reports no errors, and finds some items which need manual review. -I regularly run axe-core, the IBM Equal Access Accessibility Checker, the Nu HTML Checker (local build, latest commit), and webhint on every page in my sitemap. After filtering out false-positives (and reporting them upstream), I receive no errors. +I run axe-core, the IBM Equal Access Accessibility Checker, the Nu HTML Checker (local build, latest commit), and webhint on every page in my sitemap. After filtering out false-positives (and reporting them upstream), I receive no errors. I repeat this run with every change to my Hugo templates and stylesheets. -Due to [issue 1008 in IBM Equal Access Checker](https://github.com/IBMa/equal-access/issues/1008), I remove all instances of `content-visibility` from my site's CSS before running `achecker` from the command line. +To work around [issue 1008 in IBM Equal Access Checker](https://github.com/IBMa/equal-access/issues/1008), I remove all instances of `content-visibility` from my site's CSS before running `achecker` from the command line. Compatibility statement ----------------------- -The website is built on well structured, semantic, [polygot XHTML5](https://www.w3.org/TR/html-polyglot/) (including [WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/) and [DPUB-ARIA](https://www.w3.org/TR/dpub-aria-1.1/) extensions where appropriate), enhanced with CSS for styling. The website does **not** rely on modern development practices such as CSS Grid, Flexbox, SVG 2, Web fonts, and JavaScript; this should improve support in older browsers such as Internet Explorer 11. No extra plugins or libraries should be required to view the website. +This website uses well structured, semantic, [polygot XHTML5](https://www.w3.org/TR/html-polyglot/) (including [WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/) and [DPUB-ARIA](https://www.w3.org/TR/dpub-aria-1.1/) extensions where appropriate), enhanced with CSS for styling. -This site sticks to Web standards. I regularly run a local build of [the Nu HTML Checker](https://github.com/validator/validator), `xmllint`, and [html proofer](https://github.com/gjtorikian/html-proofer) on every page in my sitemap, and see no errors. I do [filter out false Nu positives](https://git.sr.ht/~seirdy/seirdy.one/tree/master/item/linter-configs/vnu_filter.jq) and report them upstream when I can. +This website does **not** rely on modern development practices such as CSS Grid, Flexbox, SVG 2, Web fonts, and JavaScript; this improves support in older browsers such as Internet Explorer 11. Users can access this site without extra plug-ins or polyfills. The site does use strictly-optional modern features (e.g. CSS containment) that don't create significant visual differences. -I also perform cross-browser testing for both HTML and XHTML versions of my pages. I test with, but do not necessarily endorse, a large variety of browsers: +This website conforms to Web standards. Each build runs `xmllint` to catch syntax errors. Every few commits, I run a local build of [the Nu HTML Checker](https://github.com/validator/validator) and [html proofer](https://github.com/gjtorikian/html-proofer), and see no errors. I do [filter out false Nu positives](https://git.sr.ht/~seirdy/seirdy.one/tree/master/item/linter-configs/vnu_filter.jq), and I [report and fix false-positives](https://github.com/w3c/css-validator/issues?q=author%3ASeirdy) when possible. + +I also perform cross-browser testing for HTML [and XHTML versions](#markup) of my pages. I test with, but [do not necessarily endorse]({{}}), a large variety of browsers: Mainstream engines -: I maintain excellent compatibility with mainstream engines: Blink (Chromium, Edge, QtWebEngine), WebKit (Safari, Epiphany), and Gecko (Firefox). +: I keep excellent compatibility with mainstream engines: Blink (Chromium, Edge, QtWebEngine), WebKit (Safari, Epiphany), and Gecko (Firefox). Tor Browser -: My Tor hidden service also works well with the Tor Browser, with the exception of [a page containing an `