Hi Alastair, it would pass if it provides one on its own -- my proposal is that if the sample styling isn’t displayed when applied then it can pass by providing it itself directly or via some mechanism like toggle.
Jonathan
From: Alastair Campbell <acampbell@nomensa.com>
Sent: Thursday, January 16, 2020 1:26 PM
To: David MacDonald <david100@sympatico.ca>; Jonathan Avila <jon.avila@levelaccess.com>
Cc: WCAG list <w3c-wai-gl@w3.org>
Subject: RE: WCAG 2.2 status - Visual indicators
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I’d just point out there can be some valid cases where people hide the accessible version of a control.
For example, the BBC radio player (in the video link from before) uses a slider (visually & with mouse) for the volume. ARIA based sliders don’t currently work in mobile ATs which is (I assume) why they implemented tab-able buttons in the background to set the volume at different levels.
From the SC text for the CSS-adaptable one, it doesn’t ‘break’, and it does provide a visual indicator of it’s own, so I assume it would pass.
But I would note that as a user, it was odd that most controls took on *my* defined styles (a dark & yellow highlight), including the siblings of the volume control. I’d guess that some COGA folk might assume it was not a control, because it didn’t have the ‘usual’ highlighting. That is the point of the pluggin after all.
[cid:image002.jpg@01D5CC72.E0A8BAF0]
Including text to fail that situation would effectively ban non-standard controls, so I don’t see a way around that aspect.
-Alastair
