Re: 1.4.12 - Text Spacing

Thanks Kevin (and to Patrick for helping to develop the bookmarklet). We
have already use, and found it very helpful.



On Tue, Sep 12, 2023 at 11:27 PM Kevin Prince <kevin.prince@fostermoore.com>
wrote:

> I use the bookmarklet from https://codepen.io/stevef/full/YLMqbo It’s
> adjustable if you need to (the code is right there) but for testing you
> don’t need to.
>
> View your page, select the bookmarklet and view again. Is anything cut
> off? Fail.
>
>
>
> Kevin
>
>
>
> *Kevin Prince *
> Product Accessibility & Usability Consultant
>
> *Foster Moore*
> A Teranet Company
>
> *E* kevin.prince@fostermoore.com
> Christchurch
> *fostermoore.com <http://www.fostermoore.com/>*
>
> *From:* Steve Green <steve.green@testpartners.co.uk>
> *Sent:* Monday, September 11, 2023 6:42 PM
> *To:* Michael Livesey <mike.j.livesey@gmail.com>; Marcos Villaseñor <
> villasenor.marcos@gmail.com>
> *Cc:* Guy Hickling <guy.hickling@gmail.com>; WAI Interest Group
> discussion list <w3c-wai-ig@w3.org>
> *Subject:* RE: 1.4.12 - Text Spacing
>
>
>
> I use the Stylus extension for Chrome and created a custom stylesheet to
> apply the styles WCAG requires for testing 1.4.12. It’s not adjustable like
> the one you linked to, but it doesn’t need to be.
>
>
>
> Steve Green
>
> Managing Director
>
> Test Partners Ltd
>
>
>
>
>
> *From:* Michael Livesey <mike.j.livesey@gmail.com>
> *Sent:* Sunday, September 10, 2023 5:40 PM
> *To:* Marcos Villaseñor <villasenor.marcos@gmail.com>
> *Cc:* Guy Hickling <guy.hickling@gmail.com>; WAI Interest Group
> discussion list <w3c-wai-ig@w3.org>
> *Subject:* Re: 1.4.12 - Text Spacing
>
>
>
> Hi Guy and Marcos,
>
> many thanks both for your comprehensive replies which I think help resolve
> a lot of the confusion with 1.4.12.
>
> regarding testing, has anyone used the chrome extension for 1.4.12 or have
> any suggestions for developer tools that could help developers assess, and
> therefore pass, this criterion?
>
> Below is a link to the chrome extension.
>
>
> https://chrome.google.com/webstore/detail/text-spacing-editor/hgiacbohdkgnobadgihbamoccokjpcca
>
> On Saturday, September 9, 2023, Marcos Villaseñor <
> villasenor.marcos@gmail.com> wrote:
> > To add to what Guy and Steve note, it’s also common for designers to
> insist that developers follow their designs with “pixel perfection”,
> ignoring the fluid nature of the web. This is compounded by CMS designers
> adopting strategies (like setting artificial character limits) to prevent
> content editors using the CMS from “breaking” their design intent with more
> content than they envisioned.
> >
> >
> >
> > The result is that, if the style sheet is ever overridden, the content
> becomes inaccessible to everyone. For example, fixed size containers
> truncate text, preventing anyone from reading the full title or important
> content within an element. Navigation, tables and other content displayed
> in limited space is affected particularly badly.
> >
> >
> >
> > We test designs and implementations with the parameters set in 1.4.12
> and I personally find it a very helpful criterion to ensure that designers
> understand their work needs to be resilient, rather than beautiful but
> inflexible (as it would be in the print world).
> >
> >
> >
> > Marcos
> >
> >
> >
> > From: Guy Hickling <guy.hickling@gmail.com>
> > Date: Saturday, 9 September 2023 at 14:11
> > To: WAI Interest Group discussion list w3c-wai-ig@w3.org
> > Subject: Re: 1.4.12 - Text Spacing
> >
> > Hi Andrew,
> >
> > Steve is quite correct in what he says, and there is nothing wrong with
> the way SC1.4.12 is written. It is certainly not meaningless, if you read
> it carefully, and if the Understanding document for 1.4.12 is also read. In
> fact this is one of the clearer SCs (in spite of the complex subject it
> covers). It means, for authors, exactly what it says. If you have another
> look through the Understanding document for 1.4.12, it will perhaps become
> clearer (and you will also see that it makes clear the SC is for content
> authors, not the browsers or users).
> >
> >
> >
> > The purpose of this SC is to ensure that developers don't write CSS that
> causes problems for users using their own stylings, up the limits specified
> in the SC itself. (Users can do this using a suitable browser add-on, or
> even their own stylesheet if they are technically minded enough for that.)
> In other words, if the user decides to increase the line height to 1.5
> times the font size, for example (as some users with dyslexia do), or add
> extra space after the paragraphs to show wider separation for clarity, they
> should be able to do so without some of the text being cropped or
> disappearing.
> >
> >
> >
> > This means that web developers should not, for instance, specify both
> the height and width of a text container in px pixel units in the CSS
> (which fixes the size regardless of the text styling inside it), as that is
> highly likely to result in cropping, or other display issues, for users
> using their own styling. Using px units on containers is a actually very
> common mistake that developers not interested in accessibility make (it
> comes down to us from the early days of the Web), and that is the reason
> this SC was created - to stop exactly that kind of bad coding from the
> developer. Over-writing of adjacent text also often occurs when the
> developer uses absolute positioning of their content - another common
> mistake from pre-accessibility times - for users that are using their own
> stylings.
> >
> >
> >
> > The SC does not forbid developers to use settings below the limits
> specified in the SC (standard defaults are lower than these limits), but it
> does mean that they should test their work, up to those settings mentioned
> in the SC, to ensure none of the problems mentioned above (cropping,
> over-writing, and other things) occur. Likewise test teams in organisations
> trying to implement accessibility should also make the same test, and
> external accessibility auditors also certainly make those tests as a matter
> of course (at least, the good ones do!). So this is a very real issue that
> is tested for. (Testers can simply change the CSS in their browser using
> the developer tool, but there are also a few testing widgets available that
> apply those settings.)
> >
> >
> >
> >> " The author shall not set the viewport or..."
> >
> > Speaking purely from memory, I don't think any of the SCs mention the
> "author" as such (though the Understanding documents do). This is because
> the WCAG as a whole is specifically written for web authors - there is an
> entirely separate guidelines for the browsers and other user agents. Web
> developers who implement accessibility know that all the SCs apply to them,
> not the user or the browsers, and they know the WCAG house style for the
> SCs does not specify "author" (but the Understanding docs do).
> >
> >
> >
> >> " user style sheets are a hack at best..."
> >
> > No, they aren't a hack, they are a valid way for users with various
> impairments to adjust styling and colours to suit their own requirements
> (and browser add-ons are alternatives to do the job for the user). What
> developers must avoid is doing things that prevent users from doing so, or
> that make things difficult (such as over-writing) when they do.
> >
> >
> >
> >> " does the author “block” things like zoom or other personalizations"
> >
> > SC4.1.12 is specifically written to forbid authors from doing so. But it
> is written in a testable way, i.e. so that a specific test can be applied
> to a web page to ensure line-height and other stylings can be tested. A
> separate SC exists for when the user zooms (the Reflow SC), and that is
> also written in a testable way. In contrast, just saying "author shall not
> set the viewport or other features is such a way as to" is not easily
> testable in itself, it is a rather high-level, vague statement.So the SCs
> are worded the way they are for a reason.
> >
> >
> >
> > So I hope this clarifies that 1.4.12 is a matter for authors, not the
> browsers. Browsers should not change these style settings (for line height,
> paragraph spacing etc), unless the user chooses to do so, any more than
> developers are required to use them. But the SC says that users must not
> experience problems (up to those specified limits, preferably even beyond
> them) - but only the developer can assure that, by coding correctly; the
> browsers cannot help there!
> >
> >
> >
> > Regards,
> >
> > Guy Hickling
> >
> >
> >
> >
>