1.4.3 - CSS4 Variable Fonts - What is bold?

[michael-n-cooper]

From @joe-watkins on February 20, 2018 18:44

Looking ahead to CSS4 fonts, an author can define a font weight with an integer of 1-999, not being limited to multiples of 100.

An author can also define a font-weight with a text value of bolder or lighter which affects the font's inherited weight.

With this being said, perhaps there is an opportunity within the SC to expand upon what 'bold' means?

In terms of the number value, I'm assuming bold is anything above 700 for a font. So maybe an addition of the number value to the SC intent may help folks understand?

18 point text or 14 point bold (or a minimum font weight of 700) text is judged to be large enough to require a lower contrast ratio.

Don't want to make this more confusing but wanted to throw the idea out there :)

https://www.w3.org/TR/css-fonts-4/#font-weight-prop https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

Copied from original issue: w3c/wcag21#772

[michael-n-cooper]

From @patrickhlauke on February 20, 2018 23:46

even defining bold numerically won't actually help much, as it still depends entirely on the individual font. bottom line is that this SC has been problematic from the start (with its use of "point" from the print world, and its initial insistence that it meant "as measured on the screen" - which cannot be set nor guaranteed by authors). and the handwavy "bold" won't get any more precise by adding a number there either. IMO of course.

[michael-n-cooper]

From @patrickhlauke on February 20, 2018 23:48

An author can also define a font-weight with a text value of bolder or lighter which affects the font's inherited weight.

on that point, you always need to refer to the actual computed value (the amended understanding doc clarifies this).

[michael-n-cooper]

From @slafleche on February 21, 2018 14:23

Unless we analyze the actual font, I don't really see how we can do much more than look at the font-weight. The designer can always make bad decisions for the font or make odd stylistic choices.

[michael-n-cooper]

From @patrickhlauke on February 21, 2018 14:48

having slept on it, adding a clarification that "bold" means a (computed) font weight value of 700 and over probably won't do any harm (but yes, won't make the SC any more subjective in terms of its handwavy nature about fonts themselves).

[michael-n-cooper]

From @jake-abma on March 4, 2018 9:19

[Personal response]

There’s more to boldness than just a number like “700 and over”. Just as there is no standard for “normal” weight across typeface families, there is no standard for “bold” weight. When defined in CSS the 700 is like a criterion which ‘defaults’ to bold but this is also the case for 600.

The exact calculation is dependent on the Font Matching Algorithm. The Font Matching Algorithm in CSS decides whether the face shown is a bold variant or not. This is done using the character map of the font, data which maps characters to the default glyph for that character.

In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights. “Bolder” and “Lighter” just decrease or increase a step from the inherited value when their min or max limit is not yet reached.

The font weight numbers/sizes in CSS are not technology agnostic so by adding ‘700 and over ’ this may conflict with other technologies and going that way we should mention and define a mapping to the “CSS number approach” as we do with “CSS pixels” but I think this brings us worse off than needed. As can be seen in the CSS Fonts Module Level 4 a weight mapping for a font family with 300 and 600 weight faces is also very common.

When we take Lucida Sans as an example which has lots of typefaces, name + number specifies weights within each Lucida style and also coordinates weights between different families. Names like “UltraThin”, “Thin”, “Normal”, and “Black” suggest the visual impression of each weight. Corresponding CSS numbers, 100, 200, 400, and 800, respectively, indicate that each weight in the list is twice as dark as the previous one.

Lucida Basic font weight names combine traditional weight names with CSS font-weight numbers. But when we see the naming and their number in CSS “Thin” is 100 NOT 200 and “Black” is 800 NOT 900.

http://lucidafonts.com/fonts http://lucidafonts.com/fonts/family/lucida-sans/samples

Other progressions are also definable in this naming method. For example, in the series of Normal (400), Bold (600), and ExtraBlack (900), each successive weight is 1.5 times as dark as the previous one.

The many gradations of weight in Lucida allow a typographer or graphic designer to choose different kinds of weight progressions for different contexts

For typeface names we see however, even after a century of naming bold weights, there is still no standardization between type families, such that the bold of one family will be the same weight as the bold of another family. This makes the fixation of a number by CSS even more difficult.

When checking the history of numbers for weights we see:

• Adrian Frutiger broke with traditional weight names, which vary from language to language, and devised a two-digit decimal system of naming for consistency across languages, cultures, and nations. In Univers, light roman weight is designated “45”, normal “55”, bold “65”, black “75”, and extra black “85”.
• Linotype launched the Neue Helvetica family using the same system, in which “25” designates ultra light, “35” thin, and “95” black.
• In Univers Next, launched in 1997, the weight gamut and decimal numbering system were extend with an additional digit, “130” became ultralight, “230” thin, “330” light, “430” basic, “530” medium, “630” bold, “730” heavy, “830” black, and “930” extra black.

And of course we have the CSS variant of :

• 100 - Thin
• 200 - Extra Light (Ultra Light)
• 300 - Light
• 400 - Normal
• 500 - Medium
• 600 - Semi Bold (Demi Bold)
• 700 - Bold
• 800 - Extra Bold (Ultra Bold)
• 900 - Black (Heavy)

CONCLUSION:

As the UNDERSTANDING doc already mentiones:

"18 point" and "bold" can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient.

Adding the number makes the concept of bold more difficult to be used within the limits and rules allowed by the underlying technology. The difference between CSS Fonts Module Level 3 and CSS Fonts Module Level 4 doesn’t change this.

[michael-n-cooper]

From @jake-abma on March 4, 2018 9:20

[Proposed unofficial response] Thank you for the comment. The requirements for WCAG 2.1 (http://w3c.github.io/wcag/wcag21/requirements/) include a requirement for backward compatibility with WCAG 2.0, and this rules out a variety of potential changes to parts of the spec that originate from WCAG 2.0, including changes to 1.4.3 and to glossary definitions related to it. We will mark this comment with the "defer" label to ensure that it is considered at the appropriate time.

[michael-n-cooper]

From @patrickhlauke on March 4, 2018 12:23

@jake-abma unless i'm mistaken, the question here was about elaborating in the understanding document, which is non-normative and thus should be editable without breaking the "can't touch this" backwards compatibility requirement on the normative SC/glossary definitions part.

[michael-n-cooper]

From @joe-watkins on March 6, 2018 20:24

@jake-abma Thanks for the awesome thoughtful responses ;)

@patrickhlauke is correct - elaboration of the understanding doc in some way to help define what "bold" is and how to test for bold, both manually and automated! It is already a bit fuzzy and will get fuzzier as type matures on the web.

@jake-abma How do you recommend assessing type on the web for WCAG compliance? How do we say a font is "bold"? Particularly the 18.5px - 24px sizes.

For example, if we visit this page in current Chrome -- does this type in the H1 meet WCAG color contrast minimums and how did you arrive at this conclusion? Things get real interesting when you introduce a variable font with font-variation-settings, wght, and wdth on a font with font-weight: normal; defined. Programmatically, I'd say this font isn't bold but sure looks bold.

https://s.codepen.io/joe-watkins/debug/EQqKeo

[michael-n-cooper]

From @lauracarlson on March 6, 2018 20:47

Hi Jake,

@jake-abma wrote:

[Proposed unofficial response] Thank you for the comment. The requirements for WCAG 2.1 (http://w3c.github.io/wcag/wcag21/requirements/) include a requirement for backward compatibility with WCAG 2.0, and this rules out a variety of potential changes to parts of the spec that originate from WCAG 2.0, including changes to 1.4.3 and to glossary definitions related to it. We will mark this comment with the "defer" label to ensure that it is considered at the appropriate time.

Maybe consider adding that the Working Group will move this issue to the WCAG 2.0 repo because it affects a 2.0 understanding document. Then the last sentence in the proposed response can be deleted.

[michael-n-cooper]

From @WayneEDick on March 6, 2018 21:44

Joe, This is an interesting idea, but I'm not sure bold would produce the same readability effect as 18pt. The 18pt. font takes more space, has larger differences between ascenders, descenders and the midpoint. The bowls are also larger. All of the typographic differences enhance readability in a way that a smaller font in bold may not be able to achieve. Since this is targeted at people with compromised visual acuity or sever field loss, slight difference like this can make large differences in readability.

Sincerely, Wayne

On Tue, Feb 20, 2018 at 10:44 AM, Joe Watkins notifications@github.com wrote:

Looking ahead to CSS4 fonts, an author can define a font weight with an integer of 1-999, not being limited to multiples of 100.

An author can also define a font-weight with a text value of bolder or lighter which affects the font's inherited weight.

With this being said, perhaps there is an opportunity within the SC to expand upon what 'bold' means?

In terms of the number value, I'm assuming bold is anything above 700 for a font. So maybe an addition of the number value to the SC intent may help folks understand?

18 point text or 14 point bold (or a minimum font weight of 700) text is judged to be large enough to require a lower contrast ratio.

Don't want to make this more confusing but wanted to throw the idea out there :)

https://www.w3.org/TR/css-fonts-4/#font-weight-prop https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/772, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF8fWlBGmpN1rQ12yTa5y44e5H-z9ks5tWxKjgaJpZM4SMcLo .

[michael-n-cooper]

From @patrickhlauke on March 6, 2018 22:59

@WayneEDick the use of "18pt or 14pt bold" has been in WCAG 2.0 for ages, and was not up for debate as part of the 2.1 work. @joe-watkins' issue here is simply to further clarify that "bold", in scenarios where font weight is set numerically in CSS, would equate to "700 or higher"

[michael-n-cooper]

From @WayneEDick on March 7, 2018 1:55

Why would that change contrast ratio?

On Tue, Mar 6, 2018 at 2:59 PM, Patrick H. Lauke notifications@github.com wrote:

@WayneEDick https://github.com/wayneedick the use of "18pt or 14pt bold" has been in WCAG 2.0 for ages, and was not up for debate as part of the 2.1 work. @joe-watkins https://github.com/joe-watkins' issue here is simply to further clarify that "bold", in scenarios where font weight is set numerically in CSS, would equate to "700 or higher"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/772#issuecomment-370960021, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF1po_cvG1aJNy65OpuHpJEyAHn2Cks5tbxTggaJpZM4SMcLo .

[michael-n-cooper]

From @jake-abma on March 7, 2018 8:18

@joe-watkins

Exactly, that is what my whole response is all about!

In the end "Bold" is a judgement call from the tester based on the visual appearance. Or at least it should be. The why is because the number doesn't say anything about whether it's truly 'bold' or not. It is an indicator though and sets a benchmark.

What CSS does is just to place a benchmark for what is normal, bold, black etc., and numbers 'snap' to these benchmarks. As I've written in the previous comment about what's in the Understanding doc:

"18 point" and "bold" can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient.

So here we see that in general this benchmark is seen as sufficient and for most fonts you're 'kind of save'.

But your example shows that it doesn't always work and this is also the case for fonts faces who can be considered as 'in between'. I know of fonts created specifically for companies on basis of a existing font where the result is that the 'normal' is somewhere between 'thin' and 'normal', the 'bold' somewhere between 'normal' and 'bold' and because the 'bold' is not bold enough they created an extra bold that looks bold... :-) ... get it?

The gray tone of text, the ratio of the thickness of vertical stems in letters like ‘l’ to its font x-height is a way that type designers measure relative weights. A more accurate way to indicate visual weight is to measure the percentage of black pixels in the total area of the typeface body when the font is set solid, that is, with no extra leading or inter-line spacing. And we're not even talking about color font palettes.

So unless we place the screen in a vacuüm space, calibrate the lightness and use a spectrometer on each glyph to really get a number for the density we are left with a benchmark and human judgement call... LOL

"700 and over" is not the correct number if you ask me, if used it should be "550 and over for CSS only" (snaps to 700 if I'm right) but that is nothing more than a CSS trick to pick a font face.

My suggestion is to leave bold as is, have CSS decide on basis of a number if a bold face should be used (550 or higher) and as a tester judge on experience and knowledge.

Bold is also used in the normative definition for 'large scale' (text)

large scale (text) with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#larger-scaledef

[michael-n-cooper]

From @patrickhlauke on March 7, 2018 8:50

@jake-abma in the end, both "bold" and the applicability of "18 points" and "14 points" is a judgement call really, but here we are...WCAG 2.0 uses these terms normatively. The point of understanding doc is then to translate that into something that authors and testers can understand and hopefully makes stuff testable - and judgement calls are tricky to make testable, which is why we gravitate towards "good enough I guess" numbers. Long story short: I'm in favour of adding a tiny extra clarification that gives a numeric value for "bold". Yes, it will depend on the specific font, but so does pretty much everything else in this ill-conceived SC.

Maybe, in addition to saying what font-weight value can be considered bold, the understanding needs a new note that pretty much says, to paraphrase "...but use your judgement, as this depends heavily on the font itself", in the same way the CJK have been handwaved (related, I'm sure there's more languages where this would also apply to...)

[michael-n-cooper]

From @mraccess77 on March 7, 2018 13:30

@jake-abma wrote "700 and over" is not the correct number if you ask me, if used it should be "550 and over for CSS only" (snaps to 700 if I'm right) but that is nothing more than a CSS trick to pick a font face.

I’m sorry, I can’t live with that. For me a font weight of 550 is not bold – using some sample English fonts and comparing CSS bold to CSS 550 there is stark difference. Comparing CSS bold to 700 looks the same to me. While I agree there are differences in font strokes and this can make a big difference – dropping to 550 for all fonts allows people to meet a lower threshold without providing sufficient weight for users with low vision.

[michael-n-cooper]

From @jake-abma on March 7, 2018 14:6

@mraccess77 I took the 550 because of the mapping at https://www.w3.org/TR/css-fonts-4/#bolderlighter where 550 'jumps' to 700, if no other face is present like 600, and 549 'jumps' to 400

I also asked Wilco Fiers and in aXe they use >600 for checking bold.

In the end it's up to the typographer to make the font face 'big' enough so we experience it as bold

[michael-n-cooper]

From @mraccess77 on March 7, 2018 14:31

@jake-abma As long as the end effect of a relative bolder based on inheritance comes out as 700+ that is fine. I wasn't clear from your post if you were talking about relative bolder or bold. But from what I hear now you are saying if some element has a 550 weight font and then applies bolder to a descendant we should come out with a weight of 900 on the descendant. That makes sense.

[michael-n-cooper]

From @patrickhlauke on March 7, 2018 16:10

@jake-abma bolder/lighter etc is probably muddying the waters here. we're talking about the absolute font-weight computed value, and what numerically should be bold. going just a bit further up on the same spec https://www.w3.org/TR/css-fonts-4/#font-weight-prop we have

Values have the following meanings: [...] bold - same as 700.

[michael-n-cooper]

From @jake-abma on March 7, 2018 16:53

@patrickhlauke , I know that but that's the approach for/from the CSS spec makers and not a definite/absolute true, a font with 600 as bold is/can be also (mapped to) bold. But again, if you read all my comments it's just a matter of what number you place to set a benchmark.

So in the Understanding doc you could mention that CSS takes 700 as the bold benchmark but not:

18 point text or 14 point bold (or a minimum font weight of 700) ...

... in general because in my opinion that does create possible harm

[michael-n-cooper]

From @awkawk on March 7, 2018 17:17

I agree that we aren't changing the normative SC text, so it is good to focus on the Understanding content.

The way that I would suggest that we handle this is by adding a "note 3" in the intent section. Anyone want to take a crack at a concise note?

Also, we are moving ALL understanding content to the 2.1 repo, so please use that one for branches/PRs. The Understanding documents will cover 2.0 and 2.1, and the source files will be housed in the 2.1 repo.

[michael-n-cooper]

From @patrickhlauke on March 7, 2018 18:56

@patrickhlauke , I know that but that's the approach for/from the CSS spec makers and not a definite/absolute true, a font with 600 as bold is/can be also (mapped to) bold.

as in if a page uses a particular font, and the author sets font-weight: bold, it then resolves to a computed value that is not font-weight: 700? any examples?

or are you talking about the possibility that a designer chooses a font that has its bold form already at another numerical value, and sets that value in their CSS, so the computed value is below 700? if so, i'd say that auditors can't be expected to unambiguously test for that, as you'd be saying they need to either know that particular font (and know that it actually maps bold to some other number) or eyeball it...which goes against the idea of having unambiguous numbers to test against. because once we go down that route, we'd also have to question the "18 points or 16 points" part, as fonts can be designed to appear big or small regardless of what the point size is, and we don't currently ask auditors to interpret/use their own judgement on that front either - we refer to the computed values.

[michael-n-cooper]

From @patrickhlauke on March 7, 2018 18:58

so, if we're adding a note that "smears" the exact value a bit because fonts can be different for the font weight, we should also fudge it for the point size I'd say...which then makes the whole SC essentially non-testable as it relies on a judgement call by auditors/authors.

[michael-n-cooper]

From @jake-abma on March 8, 2018 8:39

@patrickhlauke

or are you talking about the possibility that a designer chooses a font that has its bold form already at another numerical value, and sets that value in their CSS, so the computed value is below 700? if...

Yes! See my code pen for examples and check 549, 550 for Arial and Lucida weight numbers at: https://codepen.io/Jake-Abma/pen/xPNVWx

And please check the facts from Lucida, This is why 700 and up is just not an absolute truth for Bold.

Lucida Facts: http://lucidafonts.com/pages/facts

To avoid confusion, Lucida Basic fonts use numerical designations based on the W3C-CSS weight numbering system combined with descriptive names derived from traditional weight names.

=> Normal weight = 400 AND Bold weight = 600 !!!

Lucida CSS Values:

UltraThin   100 100UtThin
ExtraThin   150 150XtThin
Thin        200 200Thin
ExtraLite   240 250XtLite
Lite        300 300Lite
Book        350 350Book
Text        375 375Text
Normal      400 400Norm
Thick       425 425Thick
ExtraThick  450 450XtThik
Dark        500 500Dark
ExtraDark   550 550XtDark
Bold        600 600Bold
ExtraBold   650 650XtBold
UltraBold   700 700UtBold
Black       800 800Black
ExtraBlack  900 900XtBlak
UltraBlack  999 999UtBlak

[michael-n-cooper]

From @jake-abma on March 8, 2018 8:42

(ps. I only added normal and bold for Lucida, not all other faces...)

[michael-n-cooper]

From @patrickhlauke on March 8, 2018 10:27

the codepen doesn't work as loading the extra font is blocked due to CORS policy in browsers.

However, if I understand what you're saying, then yes I agree that bold/700 and even 18 points/16 points are, in essence, meaningless numbers as they vary based on the actual font used. But...here we are. WCAG 2.0 defines the points as hard numbers (as meaningless as they are in real-world). so this issue is about also providing a number for "bold". and both saying "bold" and "700" is also meaningless in the real-world application, but again, here we are.

As the point size and "bold" is in the normative SC text, we can't get around it. so as the precedent for "let's set a number even though it's probably meaningless, and let's handwave it for CJK" has been established, i see no further harm (the harm's already done) in saying that "bold" per spec resolves to font-weight:700.

but, to be honest, i particularly loathe this SC exactly because it gives a false sense of scientific correctness by providing hard figures (in terms of font size in points) which yes can be unambiguously tested (even by automated tools) but may not mean anything in real life.

i will add however, as anecdote, that prior to seeing this issue raised here, i had various two separate people in the past ask me about what "bold" would be when an author had set their font-weight using numbers...so the question itself is out there, and it would be good for the understanding doc to provide an answer.

just being mindful that if we add a note saying, in essence, "both size and weight are actually dependent on the font, so the hard figures we gave here may not be right", we're effectively undermining the entire basis on which the normative SC stands...

[michael-n-cooper]

From @jake-abma on March 8, 2018 10:37

This is why suggestion would be to add a note telling CSS uses 700 for a bold benchmark and as the understanding doc already mentioned:

"18 point" and "bold" can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient.

You're save 'most of the times'

But not like:

18 point text or 14 point bold (or a minimum font weight of 700) text is judged to be large enough to require a lower contrast ratio.

But, leave the above/Understanding text as is and add a separate note:

CSS bold bla bla ...has a minimum font weight of 700... bla bla

This way bold is just, well... 'bold', as meant by the typographer, and we stay technology agnostic

[michael-n-cooper]

From @patrickhlauke on March 8, 2018 10:39

This way bold is just, well... 'bold', as meant by the typographer, and we stay technology agnostic

this presupposes auditors use their judgement to determine if something is "bold" or not. as long as that's aknowledged (that this is all eyeballing)...

[michael-n-cooper]

From @joe-watkins on March 8, 2018 17:48

@jake-abma thanks for shedding light on the font mapping. Not being pinned down to a number makes sense to me. This would support my original post about font widths and weights in CSS 4.

I think we just need to convey in the understanding doc that it comes down to human judgement in a more clear and direct fashion. Some folks may interpret the existing documentation in that way but others don't. (I'd imagine a clearer definition would be handy during litigation as well)

e.g. "Because various web fonts map to bold typefaces differently. "bold" can be defined by human judgement."

If in the future font authors and browsers have more solid standards for folks to lean on computed styles we could poke at this again. It would be nice, then robots and more importantly people with low vision or no vision could test for this.

[michael-n-cooper]

From @WayneEDick on March 8, 2018 19:51

The understanding document is simply wrong regarding with it's calculation of 3:1. The Arditi-Knowblauch reference does not imply a linear relationship. It only shows that contrast-sensitivity increases as font size increases. As I remember, it is silent on font weight.

The American Printing House reference (now broken) is in reference to print on paper. 18pt to 14pt on paper is more like 20pt to 16pt on the monitor.

The APH says:

• 12 pt. = regular print
• 14-16 pt. = “enlarged” print (not considered large print)
• 18 and larger = large print
• 18 and larger, with other formatting changes = enhanced print
• Note: Students who need print 28 points or larger should probably be considered as candidates for Braille education.

The Note is an indicator of the focus on print. It is completely irrelevant for electronic interfaces. APH Guidelines for Print Document Design , http://www.aph.org/research/design-guidelines/.

Wayne

On Thu, Mar 8, 2018 at 9:49 AM, Joe Watkins notifications@github.com wrote:

@jake-abma https://github.com/jake-abma thanks for shedding light on the font mapping. Not being pinned down to a number makes sense to me. This would support my original post about font widths and weights in CSS 4.

I think we just need to convey in the understanding doc that it comes down to human judgement in a more clear and direct fashion. Some folks may interpret the existing documentation in that way but others don't. (I'd imagine clearer definication handy during litigation as well)

e.g. "Because various web fonts map to bold typefaces differently. "bold" can be defined by human judgement."

If in the future font authors and browsers have more solid standards for folks to lean on computed styles we could poke at this again. It would be nice, then robots and more importantly people with low vision or no vision could test for this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/772#issuecomment-371566948, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF1z-5s0FATViepRuCnq80UEWN7nTks5tcW8OgaJpZM4SMcLo .

[michael-n-cooper]

From @DavidMacDonald on March 20, 2018 21:5

Perhaps add a sentence like this to the understanding

Many font faces become bold at a weight of about 700.

[michael-n-cooper]

From @awkawk on March 20, 2018 21:7

WG decided to defer a decision on how to address this issue in the Understanding document until it has more time when WCAG 2.1 reaches PR or REC.

[alastc]

Noting that #665 overlaps with this one a lot, we should close one and reference from the other.

Given that #665 wasn't imported to this repo, let's close this issue.

Pinging the current participants: @WayneEDick, @patrickhlauke, @jake-abma, @DavidMacDonald, @joe-watkins, @awkawk, @mraccess77, @lauracarlson

This is closed but not forgotten..

[WayneEDick]

I have just spent time doing a mini lit review, and cannot fine reading speed experiments that use font weight.

I'll look a little more.

Best, Wayne

On Wed, May 8, 2019 at 10:02 AM Alastair Campbell notifications@github.com wrote:

Closed #341 https://github.com/w3c/wcag/issues/341.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/341#event-2327872341, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4FYBNFEAMYUBPRA4BWDPUMBQ3ANCNFSM4FESSSPQ .

[alastc]

Hi Wayne,

If you find something, please add it to #665, thanks.