-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change markers: add New visual style and remove unnecessary "text semantics" #1481
Conversation
Make it more visually obvious
Not convinced this adds any majorly useful semantics - not read out by AT by default unless you go character by character, and it's not really needed to delimit the change marker which sits in its own little paragraph (i.e. it's not delimiting start/end of a whole section that's changed, or similar)
I have added an erratum label to this, since despite the fact it is a non-normative change, it is in the TR and therefore will be recorded on the errata page. |
The "New" was removed from the third note of 5.2.2 Full pages in the September 2023 publish, as shown in this screenshot. It is captured in the errata and change log:
|
The use of "[New]" now appears in only one location in the September 2023 version of 2.1, immediately under the heading It appears in two contexts in the 2.2 TR:
Note that the location of this "New" text varies between the definition and the SCs (as well as from where it appears in the 2.1 screenshot above). It immediately follows the level information for the SC: The CSS styling appears to qualify as a level 1 w3c class of change ("No changes to text content: These changes include fixing broken links, style sheets, or invalid markup."), and can be immediately pushed once it meets WG approval. |
Thanks for checking @mbgower |
@patrickhlauke I just wanted to confirm with you that all 3 different positions of the New 'tag' are supported by your change, and that it can handle both the single occurrence in 2.1 and the 15 additional in 2.2? |
@mbgower yes, the changes in this PR do support them Lone one in 2.1 One of the ones from 2.2 |
If we want to meet AAA standards, we could change the red colour to #B50000 - this would meet AAA contrast requirements at all text sizes. |
@alastc just checking, what's the status of this? |
I am slightly averse to using red to highlight something that is new. In the design components for WAI (admittedly not TR space), red is use for a deprecated message. Yellow is used for all other messages. We don't have anything specifically for 'new' - might be worth us thinking about that. |
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@mbgower NO (sorry, my British 'slightly averse' is really 'I don't like this at all'). Red is not to be used for marking 'new' content. Whilst it is visually salient it is used much more frequently for alerts and errors. |
should i do a follow-up using the blue? i actually agree it might look more appropriate #1481 (comment) |
That would be great @patrickhlauke. The WAI color palette might give you some other ideas. As long as it is not red ;) |
Instead of the original red - see #1481 (comment)
Instead of the original red - see #1481 (comment)
…antics" (#1481) In WCAG 2.1 there's one change marker for the third note in "Full pages" https://www.w3.org/TR/WCAG21/#cc2 - this currently looks odd/just like an awkward start of the sentence. > ![WCAG 2.1 third note in 'Full pages', with 'New' at the start of the paragraph looking like it's just part of the sentence](https://user-images.githubusercontent.com/895831/96334873-e2599980-106b-11eb-9d28-775789405927.png) In WCAG 2.2, there's a few more change markers, and these use JavaScript to add "text semantics", wrapping them in square brackets. but these don't - to my mind at least - add anything useful ... they're not read out by default by AT unless you go character by character, and as they just live in their own little paragraph, they don't really need to delimit start/end of anything and are just as understandable without the square brackets. > ![one of WCAG 2.2's '[New]' change markers](https://user-images.githubusercontent.com/895831/96336427-9ca2ce00-1077-11eb-8ca2-f3db0f24bf22.png) **This PR adds a more visually explicit style, and removes the square brackets** ![WCAG 2.1 third note in 'Full pages', with 'New' at the start of the paragraph, now styled as bold white text on a red box with slightly rounded corners, like a tag/badge](https://user-images.githubusercontent.com/895831/96336449-c78d2200-1077-11eb-8b8b-47c50ac601a5.png) ![one of WCAG 2.2's 'New' change markers, styled as bold white text on a red box with slightly rounded corners, and without the square brackets around the word](https://user-images.githubusercontent.com/895831/96336471-fefbce80-1077-11eb-8683-00639fc6e18c.png) (cherry picked from commit c050bcc)
Instead of the original red - see #1481 (comment) (cherry picked from commit 104b82b)
In WCAG 2.1 there's one change marker for the third note in "Full pages" https://www.w3.org/TR/WCAG21/#cc2 - this currently looks odd/just like an awkward start of the sentence.
In WCAG 2.2, there's a few more change markers, and these use JavaScript to add "text semantics", wrapping them in square brackets. but these don't - to my mind at least - add anything useful ... they're not read out by default by AT unless you go character by character, and as they just live in their own little paragraph, they don't really need to delimit start/end of anything and are just as understandable without the square brackets.
This PR adds a more visually explicit style, and removes the square brackets