css-meeting-bot
commented
1 month ago The ARIA Authoring Practices (APG) Task Force just discussed 1.4.3 Contrast Failure in Feed Example.
The full IRC log of that discussion
<jugglinmike> TOPIC: 1.4.3 Contrast Failure in Feed Example<jugglinmike> github: https://github.com/w3c/aria-practices/issues/3149
<lola> q+
<jugglinmike> Matt_King: IN THE FEED EXAMPLE, IN THE IFRAME, WE HAVEN'T SPECIFIED A TEXT COLOR FOR TWO OF THE ELEMENTS
<jugglinmike> siri: IF THE COLOR IS NOT SPECIFIED THAN HOW IS THE COLOR PROVIDED?
<jugglinmike> Matt_King: MY ASSUMPTION IS THAT IT IS INHERITED
<jugglinmike> Matt_King: TECHNICALLY, AS IT STANDS, THAT CONTRAST IS PROBABLY SUFFICIENT. BUT IF YOU'RE TESTING THIS IN THE WAY F24 SUGGESTS, THOUGH...
<jugglinmike> Matt_King: F24 MAY BE GOING BEYOND THE REQUIREMENT HERE. I DIDN'T KNOW THAT 1.4.3 DIDN'T INCLUDE THIS ASPECT OF "ROBUSTNESS" FOR COLORS
<jugglinmike> siri: MAYBE SOMETIMES YOU WILL INHERIT DIFFERENT COLORS FROM THE PARENT
<jugglinmike> lola: THE DEFAULT TEXT COLOR WOULD BE SET IN THE BROWSER'S INTERNAL CSS, AND IT IS USUALLY (AT LEAST IN "LIGHT" MODE) BLACK (OR A COLOR SIMILAR TO BLACK)
<jugglinmike> lola: ACCORDING TO THIS F24, IT'S GOING TO FAIL BECAUSE THE COLOR HASN'T BEEN SET. IS THERE ANY HARM IN EXPLICITLY SETTING THE COLOR JUST SO THAT DOESN'T FAIL, EVEN IF WE SET IT TO THE SAME COLOR IT WOULD TAKE BY DEFAULT?
<jugglinmike> Matt_King: NO, THERE WOULD BE NO HARM IN THAT
<jugglinmike> Adam_Page: I DON'T KNOW THAT I AGREE WITH THIS REQUIREMENT. IT FEELS... OLD
<jugglinmike> Matt_King: YEAH, ANYTHING RELATED TO PERSONAL STYLESHEETS FEELS LIKE A 90'S PROBLEM TO ME
<jugglinmike> Matt_King: IT FEELS MORE LIKE A ROBUSTNESS ISSUE TO ME RATHER THAN A STRAIGHT-UP FAILURE
<jugglinmike> Adam_Page: ANY USER WHO HAS THE CONDITIONS THAT WOULD ACTUALLY CAUSE A PROBLEM HERE WOULD BE EQUIPPED TO RESOLVE IT THEMSELVES (BECAUSE THEY WOULD BE RESPONSIBLE FOR HAVING SELECTED A NON-DEFAULT COLOR VALUE IN THE FIRST PLACE)
<siri> agreed
<jugglinmike> CurtBellew: INTERNALLY, WE HAVE A TESTING TOOL, AND I DEFINITELY DON'T TEST FOR THIS
<jugglinmike> s/AND I/AND WE/
<jugglinmike> Matt_King: THIS HAS GOTTEN WAY MORE INTERESTING THAN I THOUGHT IT WAS GOING TO GET!
<jugglinmike> Matt_King: IF THIS PROBLEM APPEARS IN THIS ONE SPOT IN APG, THEN I HAVE A HARD TIME IMAGINING THAT IT DOESN'T OCCUR IN MANY OTHER PLACES, TOO
<jugglinmike> Matt_King: THAT SAID, I DON'T MIND MAKING A CHANGE HERE.
<jugglinmike> Adam_Page: I AM ABLE TO REVIEW THE PATCH
<jugglinmike> Adam_Page: I THINK THIS EXPOSES AN INTERESTING QUIRK OF WCAG, AND I'M INTERESTED IN TAKING THAT UP WITH THEM
<jugglinmike> Adam_Page: BUT I THINK THIS PAGE DOES A GOOD JOB BRINGING US TO ALIGNMENT WITH PRESENT-DAY WCAG
<jugglinmike> siri: SHOULD WE ADD A NOTE ABOUT THIS?
<jugglinmike> Matt_King: I DON'T WANT TO BRING TOO MUCH ATTENTION TO IT
<jugglinmike> siri: I CAN ALSO REVIEW
<jugglinmike> Matt_King: THANKS TO YOU BOTH!
On the Infinite Scrolling Feed Example page, within the iframe embedded, the background color is specified, but elements with the selectors
h3and.restaurant-namedo not have a defined text color, causing a 1.4.3 contrast failure as outlined in WCAG Technique F24.To resolve this, I'm creating a pull request setting a fallback text color for these elements to ensure compliance with WCAG contrast requirements.