E-mail List Archives
Thread: Is it ok to intentionally break WCAG 2.5.3?
Number of posts in this thread: 7 (In chronological order)
From: glen walker
Date: Sat, Aug 20 2022 10:55AM
Subject: Is it ok to intentionally break WCAG 2.5.3?
No previous message | Next message →
Seems like a silly question to ask if it's ok to intentionally break any
WCAG.
I have a button that brings up a dialog with some accessibility features
(change the color theme, line spacing, font size, etc). Even though the
dialog has more options than the font size, the client chose to display the
button that opens it with an "AA", where the first capital A is small and
the second is bigger, which is a common way to show font sizes. It's
similar to the "change case" button in Microsoft Word but they use a
captial A and a small a. Microsoft decided to set the button name to
"change case".
Anyway, WCAG 2.5.3 says that the visible label must exist in the accessible
name. The logical name for the button is "accessibility options" (or
something like that) but the button displays "AA". I was going to
recommend the sensible name and not recommend that they put "AA" in the
name, but this intentionally breaks 2.5.3. For conformance purposes, they
could have "accessibility options (AA)" but that just sounds weird with a
screen reader and doesn't make the UX any better, at least for the screen
reader user.
Now a speech interface user, such as Dragon, won't know the button is
called "accessibility options" so if they say "Click AA", nothing will
happen. In general, I always encourage conformance with 2.5.3 but this one
is tricky. The Dragon user can say "click button" and see all the buttons
numbered and easily select it, and at some point they can find out the
accessible name and use it with the "click" command.
Have you ever recommended an accessible name that does not match the
visible label?
From: Birkir R. Gunnarsson
Date: Sat, Aug 20 2022 11:05AM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | Next message →
You could create a group element with a label around te button (or
buttons, if there are multiple).
<div role="group" aria-label="Chnage text sizes">
<button>AA</button>
<button>AAA</button>
</div>
That way you give the screen reader user the context of the buttons
(they are quite unlikely to ever need them, but possibly a low vision
user with speech turned on would), without having to hide the visible
text label of the button in its accessible name.
On 8/20/22, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Seems like a silly question to ask if it's ok to intentionally break any
> WCAG.
>
> I have a button that brings up a dialog with some accessibility features
> (change the color theme, line spacing, font size, etc). Even though the
> dialog has more options than the font size, the client chose to display the
> button that opens it with an "AA", where the first capital A is small and
> the second is bigger, which is a common way to show font sizes. It's
> similar to the "change case" button in Microsoft Word but they use a
> captial A and a small a. Microsoft decided to set the button name to
> "change case".
>
> Anyway, WCAG 2.5.3 says that the visible label must exist in the accessible
> name. The logical name for the button is "accessibility options" (or
> something like that) but the button displays "AA". I was going to
> recommend the sensible name and not recommend that they put "AA" in the
> name, but this intentionally breaks 2.5.3. For conformance purposes, they
> could have "accessibility options (AA)" but that just sounds weird with a
> screen reader and doesn't make the UX any better, at least for the screen
> reader user.
>
> Now a speech interface user, such as Dragon, won't know the button is
> called "accessibility options" so if they say "Click AA", nothing will
> happen. In general, I always encourage conformance with 2.5.3 but this one
> is tricky. The Dragon user can say "click button" and see all the buttons
> numbered and easily select it, and at some point they can find out the
> accessible name and use it with the "click" command.
>
> Have you ever recommended an accessible name that does not match the
> visible label?
> > > > >
--
Work hard. Have fun. Make history.
From: Patrick H. Lauke
Date: Sat, Aug 20 2022 12:02PM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | Next message →
In this case, the "aA" text isn't really representing text/a word, but
it's arguably more a graphic. So I wouldn't ding this under 2.5.3.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Sat, Aug 20 2022 12:08PM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | Next message →
On 20/08/2022 19:02, Patrick H. Lauke wrote:
> In this case, the "aA" text isn't really representing text/a word, but
> it's arguably more a graphic. So I wouldn't ding this under 2.5.3.
Ah, forgot that the understanding doc actually touches on this too
https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html#symbolic-text-characters
Long story short, not a failure.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Steve Green
Date: Sat, Aug 20 2022 1:09PM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | Next message →
More generally, the WCAG definition of text is "sequence of characters that can be programmatically determined, where the sequence is expressing something in human language" and human language is defined as "language that is spoken, written or signed (through visual or tactile means) to communicate with humans".
https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html#dfn-text
https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html#dfn-human-language
This explains why "aA" is not considered to be text. Likewise, an "x" character is not text when used as a "Close" button, so that would not fail SC 2.5.3. The same applies in other scenarios, such as "i" icons for information popups.
A further consequence is that the non-text colour contrast requirement of 3:1 applies to those characters, not the 4.5:1 ratio required for text.
Steve Green
Managing Director
Test Partners Ltd
From: glen walker
Date: Sat, Aug 20 2022 1:34PM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | Next message →
Good stuff, thanks everyone. I read the "understanding" sections so often
that I'm not sure how I missed this one.
And I use "close" or "info" all the time for x-close buttons and "i"
buttons but for some reason it didn't click as the same scenario for "AA".
And now I know what "human language" is too, thanks Steve. If I have any
buttons with Klingon labels, "human language" wouldn't apply unless I'm
speaking Klingon to another human.
From: Birkir R. Gunnarsson
Date: Sat, Aug 20 2022 8:36PM
Subject: Re: Is it ok to intentionally break WCAG 2.5.3?
← Previous message | No next message
That's the coolest thing about this list. I always learn or relearn
something about accessibility on here, going on 15 years now.
On 8/20/22, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Good stuff, thanks everyone. I read the "understanding" sections so often
> that I'm not sure how I missed this one.
>
> And I use "close" or "info" all the time for x-close buttons and "i"
> buttons but for some reason it didn't click as the same scenario for "AA".
>
> And now I know what "human language" is too, thanks Steve. If I have any
> buttons with Klingon labels, "human language" wouldn't apply unless I'm
> speaking Klingon to another human.
> > > > >
--
Work hard. Have fun. Make history.