Add Site Design Standards

2026-08-13 08:42:14 +00:00
parent bf52680fbb
commit 5d91a2c375
1 changed files with 9 additions and 0 deletions
@@ -0,0 +1,9 @@
 <br>Posted 2022-06-10 by Seirdy on their Website. 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) refer to CSS pixels. For more information about seirdy.one’s accessibility-related work, read Best practices for inclusive textual websites. The Web Content Accessibility 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. Fully conformant means that the content conforms to the accessibility standard without any exceptions. 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. The WCAG presents a starting point, not a stopping point.<br>
 <br>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](https://imgur.com/hot?q=mandate%20target) 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 anyone who wants to tap the screen without clicking something. Except for text borders, I only set custom colors in response to the prefers-color-scheme: dark [Top Source Media](http://tangxj.cn:6012/janelle37a7148) 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 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.<br>
 <br>I test each WCAG success criterion with the mainstream browser engines: Blink, Gecko, and WebKit. I also accept user feedback. Feel free to contact me through any means linked on my About page. 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 run axe-core, the IBM Equal Access Accessibility Checker, the Nu HTML Checker (local build, latest commit of the validator and its CSS-Validator submodule), 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. To work around issue 1008 in IBM Equal Access Checker, I remove all instances of content-visibility from my site’s CSS before running achecker from the command line. This website uses well structured, semantic, polygot XHTML5 (including WAI-ARIA and DPUB-ARIA extensions where appropriate), enhanced with CSS for styling.<br>
 <br>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 and html proofer across all 200-something pages in my sitemap, and see no errors. I do filter out false Nu positives, and I report and fix false-positives when possible. See my docs for building and validating this site for more information. 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 HTML and XHTML versions of my pages. Fully operable in Ladybird, textual browsers, litehtml, and NetSurf. Some issues (e.g. missing ) might make the experience unpleasant, but all major functions work.<br>
 <br>Basic features in abandoned engines and Dillo. Some ancillary features may not work (e.g. forms for Webmentions and search), but users can browse and read. I use machine-friendliness as an alternative perspective to traditional search-engine-optimization, the latter of which incentivizes low-quality content. It’s a major part of what I’ve dubbed "agent optimization". This site is parser-friendly. It uses well-formed, semantic, polygot (X)HTML5 markup validated by the Nu HTML checker and xmllint. All HTML pages have an XHTML5 counterpart; the content-type HTTP header is their sole difference. All pages parse correctly with all the XHTML parsers I tried. 1. HTML classes convey Microformats vocabulary to provide IndieWeb compatibility. This improves Webmentions and enables VCard-generation. This enables many forms of content-extraction, performed by "reading mode" implementations and search engines. 3. RDFa syntax conveys Creative Commons vocabulary. Open Graph metadata. Instant-messengers and social [Top Source Media](https://miduohuyu.com/shaunalightner/8976948/wiki/How-to-SEO-WordPress-with-Skill-and-Flair) use that metadata to generate link previews. I make Atom feeds available for articles and notes, and have a combined Atom feed for both.<br>