From aab9356cf26e1481b8dde49e52b16715ae7e367a Mon Sep 17 00:00:00 2001 From: Rohan Kumar Date: Wed, 6 Apr 2022 17:42:35 -0700 Subject: [PATCH] New section on spacing, other additions - Mention checking privacy policies for 3p content - Elaborate on more mainstream examples of color overrides - Link to CSS WG docs instead of MDN for prefers-contrast since they're more detailed. - Specify that I'm just removing margins in
elements for quotations. --- assets/p/touch_targets.avif | Bin 0 -> 1614 bytes assets/p/touch_targets.png | Bin 0 -> 2326 bytes assets/p/touch_targets_dark.avif | Bin 0 -> 1692 bytes assets/p/touch_targets_dark.png | Bin 0 -> 1951 bytes content/posts/website-best-practices.gmi | 98 ++++++++++++++++------- content/posts/website-best-practices.md | 81 ++++++++++++++----- 6 files changed, 131 insertions(+), 48 deletions(-) create mode 100644 assets/p/touch_targets.avif create mode 100644 assets/p/touch_targets.png create mode 100644 assets/p/touch_targets_dark.avif create mode 100644 assets/p/touch_targets_dark.png diff --git a/assets/p/touch_targets.avif b/assets/p/touch_targets.avif new file mode 100644 index 0000000000000000000000000000000000000000..cafba172b441fe8cae7e29c03d7ca22cd53d7ba5 GIT binary patch literal 1614 zcmXv|2~?746#X$vnK5|~QMgM_>r(zU56evOhG5voC02B~M{fZTp2x7mEP^W-Y(uM|uvN1>`;}o420KlN9 z$N)?S05&^87zKi<8+$ht1E|3(Da?=ulVNS+NhXpvRuVu;ItAkWKnjiwRUPm+1+Oqd zRyXKJLjc;F32rc|P*%fa*m&jv2nC^yBNNk8al}k$?p9z+E<|kuDI|JrwiY817CQBn555-{Bnz^w0fM!py$TXl;O&=6NMyFwT=yMzHG&^S+vWP}9nZO!;~!FDTBMHe-=KmiQM%Z&4ANlkk_))mjo8U zt7W+U+KUof2HL$o>12&wO9@D_?YNA}(Rg7rqJ`Y*b39LQG~wCsOvD9~h2ER*@_1OE zkJ(Sa_Q?Hn@^IC5qASQ&y)l&UC~-U#1Aq4W>)Qjt4GuS3XIw9sYWr3$P|;lB2iJEZ z0vB84HELzSI0J5u56rb=W~yselPuuo31ce*zdRzBI26Jz>vg6YYm6{q>q9T{B8$lj z$*h_b%^O12aDM%WCV!3lbAZID|ETD>kX??Py1JJ8`7gQGiQDtK%GP>5XCJ%zwXCnv~7Q~hf{^p#PSef(eoCoXx&|_Xo{A%Yc~8VbqN{*T_LF` zrnGn8?4!<9MnV3e_<7H_j^Ig8BI2I&_f<0@J!TB8`?u3$w1a+8N&%#ZO%~ygEw{(e z${V6|`EMekdhJvKI?cZ{it5E2U`5A%w)altlWBpPWzQkEE3foCGm@?*Uwz51FV}Y9 z9-lVXtnGn;);~VJnO1shvZ1ZBr-6DfFFNELCsrrTUtiD|A)^})+VaPJm;9u=bX}RU z#uTK?>`6|wAk>8aAh2P_z|Jih-t8*V8YS1Rx^f3~@3ezXYWM%n{dq}Oh%%o&C6RxN zPT4_naeU*!De=awb`P-U@z+}$D(KJm*_3?z>EqD)R2zlYS=zfiy;&>s@#4|%jH-AD zfy@HFz2j5KrzYODtho1X{4kfPh>p3SVv!Uqc61~lbXTq1VNHA#yRp$UUi(f`HNv~s za2SmbOA0=*hpBx!!agN3m3T4MY=Qa@ zf*89lTEV}ET<>P+dt|dvI_)91=~m6fvm=tiY^^?dY#+5qta^XKjZ<&wg3PC literal 0 HcmV?d00001 diff --git a/assets/p/touch_targets.png b/assets/p/touch_targets.png new file mode 100644 index 0000000000000000000000000000000000000000..ed5e961c51ecdd1f2d249886644c4069e23899de GIT binary patch literal 2326 zcmV+x3F-EUP)tKoExiwc?fVDV5@?_PL-mPq9Ie11A^7m6}tL zT&wm|xJYo|v_XJ~Pe$5A*?mf^)Fl+4j-5d%kiV(aLi6RHnceYvZMlQJ_S$Q&z4qE` zudQ_uRyybao#$@#+bP;<_1-Ri5bK4d#%L~A-1lJtn#vaUe;k^sCMYIQqo!}@HjNlH z>Y$mrAlC09W^3#1Q}}Exa8pzz?zB#!9j*mmD=;JO$#Q+lE%Qxt_<0G;B>;vd>R~N* z2WS+m#R@3e7MZOh9^=r+3W!F)0KX9n1(?ZDDj*m&l@if-sES5;t`{Q*HW*s}6VPrl zm3IPUy99Q20VO`#L+X&}9i9vOp*wu=IZPVn z@Q~W!fV#?u4}PXhYJmHhvWsy@KU4PIhTh?RrX~u7GViw(|{GI<#a7WYY{S9S&ANkB^?dmKQ7FbrJEWQyE1-)Usm_q@yiU znD^=gd~Q_vi%g4DaFeymp)1%JvTJ+NTh8zYpiaAAjnsvj~*+im!#tfn6}T-z|c zUpeg3;pCq2;EvbOqXu#F^oC?U28Gyq@ zBFN^lzDZ?3+im=`*bLa~4mqEY+IL7KVi_IK{H9D_=zRorRKB@a$w>s+aSZ?O99>}UWc(GXy>wu4Mfw3Z9!KTqh z!1GOWh!ahb!*$5;XEZr*XPR%Njp=RCayA!B;IpK1yPml+n+$2!%_qe z>35ds9eQiv&T?pnq4@P}384TUH_xGEOa&}(N6g6PA)g8G(Wr{M1ajOef+bZIGSfkW z9I~fF5ikfFuLK-nqucF0Vj_HmNcfTstF~sRH@*Vrtlsq*^dQD;OU zR}QV5_>7(}NF1*FAy3I267PyQ2`Jjv+M%C=cBXimdjIe<@$Ot4(e58IqiA+GJz=lA z7v(tQMiOs~$6_;wVV$awW3%bCfEvw3a#NE_(1h&XTn^^3qPjpcnW0o_0xDpl0oaRJ zP+ksZlU#!c=%*Su)A|DyFkZxAYT`T~0@@}uW)W)*BA_!{#BplUF%{6eaX1%LK%SSg zCD#F{fJ_@>=3|fnF__H`074))n)=2G>YGm{Y9MydK=eQe+Hnm8&HjQQASQ^PkKIE<1*8$z_hTE472+PbLA&R)kHxR*RsKhS zHev_%uNDxeooC`U?uZEx${%Vje;678wvaPT4!;NT3@EULxEfEyT_D>E$TUmf3ejN! z3otH$F1~CPa~djUisHmyI))p;ug%oxt*T-IYpRlElKTFOQO3(tO`UF)L@k(D4hrS? zLuV-XTc(sFu!Y9JWXXj#FBI3{*<@Q_7fdhhq0!6?O&RiB60xYRryR=Myq6?eKRs;$VP29Y!aq%*$aC12c}p8HdNiy w4`?q-Ar&ALm+&(X$`>e^gt7r9vDaUrueRzD2=x;yy8r+H07*qoM6N<$f{Yzog8%>k literal 0 HcmV?d00001 diff --git a/assets/p/touch_targets_dark.avif b/assets/p/touch_targets_dark.avif new file mode 100644 index 0000000000000000000000000000000000000000..0640cb6bd6684e9007b9ef1028d44cbf2e0f2fe2 GIT binary patch literal 1692 zcmXv|3p|v07k-DyT`OC(3_|nel4@c`ixEb-#7M3UVa#Q{nVU?8FUw$E)@ZSsZN|EU z>GDNl$u&jBM@ep}Hp)o3j?2o%CS%{Rzdiro|D5MM&+|Ly004lXvJ+UuIFJfJA+L0h zilT!=dB04ju!(XW3bQCO?ZQ7009YW2{V$eR8W{QSh@C8uP2bjFP&Nc5-%X}{GCIY7ytO*!kR#4 z+M-$e>BU{eWUkk{!7zJ+GOOJAz7(gP>F%EUyHM{QBOY;P<6F^lKb3;oJj)~XYfcuG z?(AP2_22KQFtH8t5lJWc|ItDZ87Cx>&ed)l*N@fnz2&Q#bJo7!+x-@}{zhXbwdz;w zcUSfo)JZ2(DQz*UUI8jR(pj6x(TD(N^Sdus|2jxE*lN;4{LI#bkfa&Of@w8Bh!E%8ty=1E>FA za9_gd9#b$goleTFLe!!sZVCA)rL2(g0XBG#X4P)v2XjRMu^6 zj{p25Az#;FH&POm9^F205|(OfoG%!y}KFlDsTeAnlhh6gq z9aBZ>jzKL?@J))?6DOvhR-CF)OT&wWIy&v0>P8ITw& zek;H}P`fb@Y>Y(3`w%qC9UIWpiF;n(;k(R#TzQf`?rq`1y<9`?t3S7~pPHI`-#}}t zD-#~b4=%?()EfCLJ)?TtFy=v6S=GlC0^>k@zvtTytAN`kq{=bj@)uY&qQoU?`j@#C zOG>C@NJpr$*C!Ce8Zs^1ekS<(^}6ou);#<)BSL zPx}ByS4T6KH{990k>O3|vOc1Z`941PU$|S+5QfOaq#F!#W4d z*Em0NwA+>oUE)6Dzx=V7-MZsobDLZ5n@4^x+;e`O^850PUT1mIFr~i~E^a~3_B_QX zDW-k+oiqP_B`_1SU!S0_l;yrpO2c}8l@k4Ja-Ae6=2XWgr6L9TO>5ct1{a#@<%jC< z?!MuSmaWDsCkO{x;_F)-!*r8lSk5)AYS@&ylGm>xQZ_-g@(co||#BB!g4gT=!-leypCkX`= zygl0FHm4=V<&=Ij-|o`Lfe`w#@p|Z^JN!seM9djPs!EQHcYQEG}@DbWd9Ap`RG{y literal 0 HcmV?d00001 diff --git a/assets/p/touch_targets_dark.png b/assets/p/touch_targets_dark.png new file mode 100644 index 0000000000000000000000000000000000000000..1dbd4ade25d1a072bceb3790362c927815ea5d88 GIT binary patch literal 1951 zcmV;Q2VnS#P)r$%hMJIy0@cYU0TT5B?=2@wWunH3R%TlD8nx$8PC>Iejok z;t!dkQ3$_;I{irp!Z;w<4g)*l7Z`U<>M> zlFk#GX4crO{%7QF;LGHG%qGnell|}#yCWEUd*-GV(o84Dq(8PZo$d&R`XAZ3p~T-4 z?Aov)*t}u*lpD4U+lFn!wqe__ZP+&Swf@6drhc=AqAY9B;a;d{)=&shZ@RmOLJA^o z*3cI|BnTa>fi61equ=jf0e{@AAq2#BB;+zL9Y(HPeOYgd<+=pM%^E@=6oM{YUMvve z%w3$GI=5H=%^MEAQ+h9-yBJ*{9}8N4j2HVf9Mgvigd11jG9P!bF7v$`)*!jXSYW-v zUJXNWdUEMh1@^qlJQkC+>+jKUrsNZF;74ViXtXXBG%d5^;fK^zFXcaDkXx0F=xn7dX?X z5^Nk7II*bW>zM6ZFThPUDf8Fpp^>~`U?uM=0zXr{AQ@&5Nz4rDh#3r1W-zeK;Gt#) z{S7ymNM+l?k-E{!&@zCkgVDPByWO#hd@|Vx}=Kg^a(LM8P}l5+zuc->21Y{ zTNX=)QNDCG-^L?XO2T)rOFM$S)02tI<2Z(pDnCA1=Zm<)kbeiECXyr+)Wg7#-ploB zuoy!Ciz6Z3IvxXuvId2uZ4nmYlQ0hhhxC53Uf~v87DItWSybQ!YLK>whZu%pC>{*T z8vM2_A$J&q+;&CzordzJuPx<%2PV9M|9wx$1`JV}$x4;K+%R z%6z#lUcoEM^9w5T<68J)r+Qmol zMOSo1!^z>NWeGtk6E}M6U3=G!K+5iecVD6zXz>fEnCC+(ctQS#00Y>9fn)~Rk5jbb zZpaLh;cl2c_J(8~GdP!z{IG&D_J+)$pK*iS4Ta%un1UBPG|XVY-O$9$;5_05$$oqU zCv{m)J5T=+U4w^~`AoYu-~w+YO6j+0Qwc^;urHjjk9}zeX50-Y+zn;GzN+fUfKUGbyaijZ1zWHM zTae1KR%6`HNHqhqZ1sE47R|uR%NiU5oVDtxWQyY&~sw8TIX?8f%Gvx z4{2Sz3d2674TmfWD&_Kgly7?y*T?2qE@M#$hoxitERUHd2f1JdOUDcb@)6C4`gfTH zkL9r9@!#Ui=LU%#-2Z)PLCFl_4%nGi=}!+14m#C;40j4WT$bgsyeiA>)m3>Vn}K(K z`E7YO4Z*t!5}PH)*v%$MOnL{D4I9#QHkclq&8jzXFpba^fnOuoYI(bcr|hugsi3Qa->6zH3r1%tC$G&}gV)$dGY z-4hWc7&DsKdt)a63VWpI^gU2WAjcl@iYSzvAZ=mc1D$%+rH}z~g*|dSi%{nI(dfFj z6{QrD(p_C+kBqLA=ZcHsJPdoUPgmk}oo|=eBfgd-cVlVUr<9tr2US6&oH$J<^hN-0juqTFJSXu3u;P#s@UL>fd<|4gBI=p&ZkjIS_S lfiZ^?!m&04NTSV?$XAotKQ<0$2Gsxn002ovPDHLkV1mkXpr`-< literal 0 HcmV?d00001 diff --git a/content/posts/website-best-practices.gmi b/content/posts/website-best-practices.gmi index bcc3ef5..984ee64 100644 --- a/content/posts/website-best-practices.gmi +++ b/content/posts/website-best-practices.gmi @@ -105,13 +105,17 @@ Some web developers deliver resources using third-party CDNs, such as jsDelivr o Avoid third-party content, if at all possible. -If you must use third-party content, ensure that third-party stylesheets and scripts leverage subresource integrity (SRI): +If you must use third-party content, use subresource integrity (SRI): => https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity SRI on MDN => https://www.w3.org/TR/SRI/ SRI specification This prevents alteration without your consent. If you wish to be extra careful, you could use SRI for first-party resources too. +Be sure to check the privacy policies for the third party services _and_ subscribe to updates, as their practices could impact the privacy of all your users. + +For embedded third-party content (e.g. images), give extra consideration to the "Beyond alt-text" section. Your page should be as useful as possible if the embedded content becomes inaccessible. + ## Optimal loading Nearly every Internet user has to deal with unreliable connections every now and then, even the top 1%. Developing regions lack modern Internet infrastructure; high-ranking executives travel frequently. Everybody hits the bottom of the bell-curve. @@ -320,8 +324,6 @@ Using containment for content at the end of the page is relatively safe. Using i => https://www.terluinwebdesign.nl/en/css/calculating-contain-intrinsic-size-for-content-visibility/ Calculating 'contain-intrinsic-size' for 'content-visibility' -For embedded third-party content (e.g. images), give extra consideration to the "Beyond alt-text" section. Your page should be as useful as possible if the embedded content becomes inaccessible. - ## About fonts I recommend setting the default font to "sans-serif". Avoid "system-ui": it causes issues among readers whose system fonts don't cover your website's charset. @@ -490,7 +492,19 @@ The Web version of this page is an example application of Technique C25 and the The Web version of this page only uses non-default colors when a user agent requests a dark color scheme (using the "prefers-color-scheme" CSS media query; see the next subsection) and for lightening borders. Any image with a solid background may match the page background; to ensure that their dimensions are clear, I surrounded them with borders. I also set a custom color for the borders and ensure that the image backgrounds don't match the border colors. I included borders further down to break up next/prev post navigation as well as separate footers, since these elements lack heading-based delineation. When overriding color schemes or disabling CSS altogether, the page layout remains clear. -The aforementioned techniques ensure a clear page layout while respecting user-specified color schemes. +Color overrides go well beyond simple foreground and background color changes. Windows' High Contrast Mode (HCM), for instance, makes more advanced modifications: + +=> https://accessabilly.com/accessibility-issues-concerning-windows-high-contrast-mode/ Accessibility issues concerning Windows HCM + +In fact, the CSS Working Group is working on a specification for re-coloring websites: + +=> https://drafts.csswg.org/css-color-adjust-1/ CSS Color Adjustment Module Level 1 + +The Chromium team's in-progress auto dark mode will use this specification to darken websites globally: + +=> https://chromestatus.com/feature/5672533924773888 Feature: Auto Dark Mode & support for "only" in CSS color-scheme + +Websites can opt out with the "color-scheme" property, but they really shouldn't have to: stylesheets should be robust enough to handle re-coloring. ### Dark themes @@ -530,8 +544,9 @@ I personally like a foreground and background of "#eee" and "#0e0e0e", respectiv "Just disable dark mode" is a poor response to users complaining about halation: it ignores the utility of dark themes described at the beginning of this section. -If you can't bear the thought of parting with your solid-black background, worry not: there exists a CSS media feature and client-hint for contrast preferences, called "prefers-contrast". It takes the parameters "no-preference", "less", and "more". You can serve increased-contrast pages to those who request "more", and vice versa. Check MDN for more information: +If you can't bear the thought of parting with your solid-black background, worry not: there exists a CSS media feature and client-hint for contrast preferences, called "prefers-contrast". It takes the parameters "no-preference", "less", and "more". You can serve increased-contrast pages to those who request "more", and vice versa. Check these docs for more information: +=> https://drafts.csswg.org/mediaqueries-5/#prefers-contrast Media Queries Level 5, section 11.3: prefers-contrast => https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-contrast prefers-contrast on MDN ### Contrast under different conditions @@ -831,30 +846,10 @@ The HTML spec's blockquote section recommends placing a
element ins Browser default stylesheets typically give
elements extra margins on the left and right.
elements have a large indent. Combining these two properties gives the final quotation an excessive visual indent, wasting precious vertical screen space. When quoted text contains list elements (
    ,
    ,
      ), the indentation alone may fill most of a narrow viewport! -I chose to remove the margins in
      elements. If you're reading the Web version of this page with its own stylesheet enabled, in a CSS 3 compliant browser, you might notice that the blockquotes on it have a minimal indent and a thick gray border on the left rather than a full indent. These two adjustments allow blockquotes containing bulleted lists to fit on most narrow viewports, even when wrapped by a
      element. Browsers that do not support CSS 3 properties such as "padding-inline-start" will render quoted text using default stylesheets (probably with an indent), which are perfectly usable if a bit inconvenient. +I chose to remove the margins in
      elements for quotations. If you're reading the Web version of this page with its own stylesheet enabled, in a CSS 3 compliant browser, you might notice that the blockquotes on it have a minimal indent and a thick gray border on the left rather than a full indent. These two adjustments allow blockquotes containing bulleted lists to fit on most narrow viewports, even when wrapped by a
      element. Browsers that do not support CSS 3 properties such as "padding-inline-start" will render quoted text using default stylesheets (probably with an indent), which are perfectly usable if a bit inconvenient. Another example: outside the Web, I prefer indenting code with tabs instead of spaces. Tab widths are user-configurable, while spaces aren't. HTML pre-formatted code blocks, however, are best indented with two spaces. Default browser stylesheets typically represent tabs with an excessive indent, which can be annoying on narrow viewports. -### When indentation helps - -Excessive indentation can make reading difficult for narrow viewports, but preserving some indentation is still useful. - -For now, I've decided to keep the indents on list elements (
        ,
        ,
          ) since I often fill them with links. See see this article's table of contents on its Web mirror for an example: - -=> https://seirdy.one/2020/11/23/website-best-practices.html#toc Table of contents - -This indentation provides important negative space. Readers with hand tremors depend on this space to scroll without accidentally selecting an interactive element: - -=> https://axesslab.com/hand-tremors/ Hand tremors and the giant-button-problem (Axess Lab) - -On lists without visible bullets, I dropped the default indentation. I had to find other ways to ensure adequate space between links. Some examples from the Web mirror of this Gemini capsule: - -=> https://seirdy.one/2020/11/23/website-best-practices.html#webmentions The webmention list below this article separates links with timestamps and some paragraph spacing. -=> https://seirdy.one/#posts The homepage posts list separates links with descriptions. -=> https://seirdy.one/2022/02/02/floss-security.html The list of related articles at the top of one of my posts does the same. - -Once again, deviating from defaults created additional work to remove an accessibility hazard. - ### Short viewports Small phones typically support display rotation. When phones switch to landscape-mode, vertical space becomes precious. Fixed elements (e.g. dickbars) become a major usability hazard. Ironically, the WCAG’s own interactive Techniques reference is a perfect example of how fixed elements impact usability on short screens. @@ -865,7 +860,55 @@ When filtering criteria on the Quickref Reference page, a dickbar lists active f Designers often use figures to “break up” their content, and provide negative space. This is good advice, but I don’t think people pay enough attention to the flipside: splitting up content with too many figures can make reading extremely painful on a short viewport. Design maxims usually lack nuance. -There’s an ideal range somewhere between “cramped” and “spaced-apart” content. Finding this range is difficult. The best way to resolve such difficult and subjective issues is to ask your readers for feedback, giving disproportionate weight to readers with under-represented needs (especially disabled readers). +## Spacing + +The previous "small viewports" section may tempt you to make your content as dense as possible. Please don't overdo it. + +There's an ideal range somewhere between "cramped" and "spaced-apart" content. Finding this range is difficult. The best way to resolve such difficult and subjective issues is to ask your readers for feedback, giving disproportionate weight to readers with under-represented needs (especially disabled readers). + +### When indentation helps + +Excessive indentation can make reading difficult for narrow viewports, but preserving some indentation is still useful. + +For now, I've decided to keep the indents on list elements (
            ,
            ,
              ) since I often fill them with links. See see this article's table of contents on its Web mirror for an example: + +=> https://seirdy.one/2020/11/23/website-best-practices.html#toc Table of contents + +This indentation provides important non-interactive negative space. Readers with hand tremors depend on this space to scroll without accidentally selecting an interactive element: + +=> https://axesslab.com/hand-tremors/ Hand tremors and the giant-button-problem (Axess Lab) + +Readers who double-tap to jump or zoom can't do so if there's no screen region that's "safe to tap": + +=> gemini://seirdy.one/misc/touch_targets.png Phone screen with three "touch target" rectangles on top of each other, separated by blank sections labeled "space". Image from Axess Lab. + +Having clearly distinguished links also helps users decide safe places to tap the screen. See the "In defense of link underlines" section for more information. + +### Tap targets + +Tap targets should be at least 44 pixels tall and wide according to the WCAG, large enough to easily tap on a touch­screen. The WCAG makes an exception for inline targets, like links in a paragraph. + +=> https://www.w3.org/TR/WCAG22/#target-size-enhanced WCAG 2.2 Success Criterion 2.5.5: Target Size (Enhanced) + +Google has far more aggressive recommendations: it recommends raising the limit 48 pixels regardless of whether tap targets are inline, going so far as to make tap target size a ranking factor in search. + +On lists without visible bullets, I dropped the default indentation. I had to find other ways to ensure adequate tap-target size *and* provide sufficient space for readers with hand-tremors to scroll. Some examples: + +=> https://seirdy.one/2020/11/23/website-best-practices.html#webmentions The webmention list below this article separates links with timestamps and some paragraph spacing. +=> https://seirdy.one/#posts The homepage posts list separates links with descriptions. +=> https://seirdy.one/2022/02/02/floss-security.html The list of related articles at the top of one of my posts does the same. + +### Line spacing + +Increasing the line-spacing a bit will make tap targets larger and improve comprehension by readers with cognitive disabilities. A WCAG AAA Success Criterion is to allow 1.5 space units between lines. + +> Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing. + +=> https://w3c.github.io/wcag/guidelines/22/#visual-presentation WCAG 2.2 Success Criterion 1.4.8: Visual Presentation + +The WAI's Cognitive and Learning Disabilities Accessibility Task Force recommends changing this level, finding it too important to be relegated to AAA status: + +=> https://w3c.github.io/coga/extension/#changedlevels Items where WCAG 2.0 SC should be changed mentions SC 1.4.8 ## Non-browsers: reading mode @@ -988,7 +1031,6 @@ This article is, and will probably always be, an ongoing work-in-progress. Some * How exposing new content on hover is inaccessible to users with magnifiers, hand tremors, switch access, and touchscreens. * Notes on improving support for braille displays. * How to work well with caret-based navigation. -* Ways to keep tap targets large. The WCAG recommends tap targets at least 44 pixels tall and wide, large enough to easily tap on a touchscreen. Google recommends raising that to 48 pixels, going so far as to make tap target size a ranking factor in search. * How to choose phrasings such that some meaning can be inferred without understanding numbers, for dyscalculic readers. This is more applicable to posts whose main focus is not mathematical or quantitative. * How to include equations in a way that maximizes compatibility and accessibility. * Keypad-based navigation on feature phones (c.f. KaiOS devices). diff --git a/content/posts/website-best-practices.md b/content/posts/website-best-practices.md index a2e7e94..0d37182 100644 --- a/content/posts/website-best-practices.md +++ b/content/posts/website-best-practices.md @@ -126,7 +126,9 @@ Third-party content will complicate the CSP, allow more actors to track users, p Some web developers deliver resources using third-party CDNs, such as jsDelivr or Unpkg. Traditional wisdom held that doing so would allow different websites to re-use cached resources; however, all mainstream browsers engines now [partition their caches](https://privacycg.github.io/storage-partitioning/) to prevent this behavior. -If you must use third-party content, ensure that third-party stylesheets and scripts leverage [subresource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) (check the [SRI specification](https://www.w3.org/TR/SRI/)). This prevents alteration without your consent. If you wish to be extra careful, you could use SRI for first-party resources too. +If you must use third-party content, use [subresource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) (check the [SRI specification](https://www.w3.org/TR/SRI/)). This prevents alteration without your consent. If you wish to be extra careful, you could use SRI for first-party resources too. + +Be sure to check the privacy policies for the third party services _and_ subscribe to updates, as their practices could impact the privacy of all your users. For embedded third-party content (e.g. images), give extra consideration to the ["Beyond alt-text" section](#beyond-alt-text). Your page should be as useful as possible if the embedded content becomes inaccessible. @@ -547,7 +549,9 @@ Even if you set custom colors, ensure that the page is compatible with color ove This page's [canonical location](https://seirdy.one/2020/11/23/website-best-practices.html) is an example application of Technique C25 (and the related [Technique G148](https://www.w3.org/WAI/WCAG22/Techniques/general/G148)). It only uses non-default colors when a user agent requests a dark color scheme (using the `prefers-color-scheme` CSS media query; see the next subsection) and for lightening borders. Any image with a solid background may match the page background; to ensure that their dimensions are clear, I surrounded them with borders. I also set a custom color for the borders and ensure that the image backgrounds don't match the border colors. I included borders to break up bottom sections, since these elements lack heading-based delineation. When overriding color schemes, the page layout remains clear. -The aforementioned techniques ensure a clear page layout while respecting user-specified color schemes. +Color overrides go well beyond simple foreground and background color changes. Windows' High Contrast Mode, for instance, makes [more advanced modifications](https://accessabilly.com/accessibility-issues-concerning-windows-high-contrast-mode/). + +In fact, the CSS Working Group is working on a specification for re-coloring websites in {{}}. The Chromium team's in-progress [auto dark mode](https://chromestatus.com/feature/5672533924773888) will use this specification to darken websites globally. Websites can opt out with the `color-scheme` property, but they really shouldn't have to: stylesheets should be robust enough to handle re-coloring. ### Dark themes @@ -574,11 +578,11 @@ I personally like a foreground and background of `#eee` and `#0e0e0e`, respectiv "Just disable dark mode" is a poor response to users complaining about halation: it ignores the utility of dark themes described at the beginning of this section. -If you can't bear the thought of parting with your solid-black background, worry not: there exists a CSS media feature and client-hint for contrast preferences called `prefers-contrast`. It takes the parameters `no-preference`, `less`, and `more`. You can serve increased-contrast pages to those who request `more`, and vice versa. Check [prefers-contrast on MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-contrast) for more information. +If you can't bear the thought of parting with your solid-black background, worry not: there exists a CSS media feature and client-hint for contrast preferences called `prefers-contrast`. It takes the parameters `no-preference`, `less`, and `more`. You can serve increased-contrast pages to those who request `more`, and vice versa. Check section 11.3 of the W3C {{}} specification for more information. ### Contrast under different conditions -Color palettes need to be effective for different types of vision deficiencies (e.g. color blindnesses) and screens. Color blindness is a far more nuanced topic than "the inability to see some colors". {{}} explains his experience in Color blindness. Color blindness manifests in complex ways. Testing in grayscale is a great start, but it doesn't account for all kinds of color vision deficiencies. +Color palettes need to be effective for different types of vision deficiencies (e.g. color blindnesses) and screens. Color blindness is a far more nuanced topic than "the inability to see some colors". {{}} describes his experience in {{}}. Color blindness manifests in complex ways. Testing in grayscale is a great start, but it doesn't account for all kinds of color vision deficiencies. Different screens and display-calibrations render color differently; what may look like a light-gray on a cheap monitor could look nearly black on a high-end OLED screen. Try to test on both high- and low-end displays, especially when designing a dark color scheme. @@ -591,7 +595,7 @@ Some typographers insist that [underlined on-screen text is obsolete](https://pr One reason is that underlines make it easy to separate multiple consecutive inline links: -{{< picture name="underlines" alt="two lines with two consecutive hyperlinks each, one line with and one without underlines." >}} +{{}} Underlines also make it easy for color-blind readers to distinguish both the beginnings and ends of links. A basic WCAG Level A requirement is for information to not be conveyed solely through color: @@ -856,23 +860,10 @@ The HTML standard's section 4.4.4 [covers blockquotes](https://html.spec.whatwg. Browser default stylesheets typically give `
              ` elements extra margins on the left and right. `
              ` elements have a large indent. Combining these two properties gives the final quotation an excessive visual indent, wasting precious vertical screen space. When quoted text contains list elements (`
                `, `
                `, `
                  `), the indentation alone may fill most of a narrow viewport! -I chose to remove the margins in `
                  ` elements. If you're reading this page with its own stylesheet enabled, in a CSS 3 compliant browser, you might have noticed the blockquotes on it have a minimal indent and a thick gray border on the left rather than a full indent. These two adjustments allow blockquotes containing bulleted lists to fit on most narrow viewports, even when wrapped by a `
                  ` element. Browsers that do not support CSS 3 properties such as "padding-inline-start" will render quoted text using default stylesheets (probably with an indent), which are perfectly usable if a bit inconvenient. +I chose to remove the margins in `
                  ` elements for quotations. If you're reading this page with its own stylesheet enabled, in a CSS 3 compliant browser, you might have noticed the blockquotes on it have a minimal indent and a thick gray border on the left rather than a full indent. These two adjustments allow blockquotes containing bulleted lists to fit on most narrow viewports, even when wrapped by a `
                  ` element. Browsers that do not support CSS 3 properties such as `padding-inline-start` will render quoted text using default stylesheets (probably with an indent), which are perfectly usable if a bit inconvenient. Another example: outside the Web, I prefer indenting code with tabs instead of spaces. Tab widths are user-configurable, while spaces aren't. HTML pre-formatted code blocks, however, are best indented with two spaces. Default browser stylesheets typically represent tabs with an excessive indent, which can be annoying on narrow viewports. -### When indentation helps - -Excessive indentation can make reading difficult for narrow viewports, but preserving some indentation is still useful. - -For now, I've decided to keep the indents on list elements (`
                    `, `
                    `, `
                      `) since I often fill them with links (see this article's [table of contents](#toc) for an example). This indentation provides important negative space. Readers with hand tremors [depend on this space](https://axesslab.com/hand-tremors/) to scroll without accidentally selecting an interactive element. - -On lists without visible bullets, I dropped the default indentation. I had to find other ways to ensure adequate space between links. Some examples: - -- The [webmention list](#webmentions) below this article separates links with timestamps and some paragraph spacing. -- The [homepage posts list](https://seirdy.one/#posts) and the list of related articles at the top of [one of my posts](https://seirdy.one/2022/02/02/floss-security.html) separates links with descriptions - -Once again, deviating from defaults created additional work to remove an accessibility hazard. - ### Short viewports Small phones typically support display rotation. When phones switch to landscape-mode, vertical space becomes precious. Fixed elements (e.g. dickbars) become a major usability hazard. Ironically, the WCAG's own interactive Techniques reference is a perfect example of how fixed elements impact usability on short screens. @@ -888,8 +879,59 @@ When filtering criteria on [the Quickref Reference page](https://www.w3.org/WAI/ Designers often use figures to "break up" their content, and provide negative space. This is good advice, but I don't think people pay enough attention to the flipside: splitting up content with too many figures can make reading extremely painful on a short viewport. Design maxims usually lack nuance. +Spacing +------- + +The previous [small viewports](#small-viewports) section may tempt you to make your content as dense as possible. Please don't overdo it. + There's an ideal range somewhere between "cramped" and "spaced-apart" content. Finding this range is difficult. The best way to resolve such difficult and subjective issues is to ask your readers for feedback, giving disproportionate weight to readers with under-represented needs (especially disabled readers). +### Non-interactive space + +Excessive indentation can [make reading difficult](#indented-elements) for narrow viewports, but preserving some indentation is still useful. + +For now, I've decided to keep the indents on list elements (`
                        `, `
                        `, `
                          `) since I often fill them with links (see this article's [table of contents](#toc) for an example). This indentation provides important non-interactive negative space. Readers with hand tremors [depend on this space](https://axesslab.com/hand-tremors/) to scroll without accidentally selecting an interactive element. Readers who double-tap to jump or zoom can't do so if there's no screen region that's "safe to tap". + +
                          +{{}} +
                          +Image credit: Axess Labs +
                          +
                          + +Having clearly distinguished links also helps users decide safe places to tap the screen. See the [section on link underlines](#in-defense-of-link-underlines) for more information. + +### Tap targets + +Tap targets should be at least 44 pixels tall and wide [according to the WCAG](https://www.w3.org/TR/WCAG22/#target-size-enhanced), large enough to easily tap on a touch­screen. The WCAG makes an exception for inline targets, like links in a paragraph. + +Google has far more aggressive recommendations: it recommends raising the limit 48 pixels regardless of whether tap targets are inline, going so far as to make tap target size a ranking factor in search. + +On lists without visible bullets, I dropped the default indentation. I had to find other ways to ensure adequate tap-target size _and_ provide sufficient space for readers with hand-tremors to scroll. Some examples: + +- The [webmention list](#webmentions) below this article separates links with timestamps and some paragraph spacing. +- The [homepage posts list](https://seirdy.one/#posts) and the list of related articles at the top of [one of my posts](https://seirdy.one/2022/02/02/floss-security.html) separates links with descriptions + +### Line spacing + +Increasing the line-spacing a bit will make tap targets larger and improve comprehension by readers with cognitive disabilities. A WCAG AAA Success Criterion is to allow 1.5 space units between lines. + +
                          +
                          +

                          Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

                          +
                          +
                          + — + + , Success Criterion 1.4.8 Visual Presentation + + +
                          +
                          + +The WAI's Cognitive and Learning Disabilities Accessibility Task Force [recommends changing this Success Criterion's level](https://w3c.github.io/coga/extension/#changedlevels), finding it too important to be relegated to AAA status. + + Non-browsers: reading mode -------------------------- @@ -979,7 +1021,6 @@ This article is, and will probably always be, an ongoing work-in-progress. Some * How exposing new content on hover is inaccessible to users with magnifiers, hand tremors, switch access, and touch­screens. * Notes on improving support for braille displays. * How to work well with caret-based navigation. -* Ways to keep tap targets large. The WCAG recommends tap targets at least 44 pixels tall and wide, large enough to easily tap on a touch­screen. Google recommends raising that to 48 pixels, going so far as to make tap target size a ranking factor in search. * How to choose phrasings such that some meaning can be inferred without understanding numbers, for [dyscalculic readers](https://en.wikipedia.org/wiki/Dyscalculia). This is more applicable to posts whose main focus is not mathematical or quantitative. * How to include equations in a way that maximizes compatibility and accessibility. * Keypad-based navigation on feature phones (c.f. KaiOS devices).