W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2016

RE: Question: testing for non-unique id values SC 4.1.1

From: Chakravarthula, Srinivasu <srchakravarthula@informatica.com>
Date: Thu, 27 Oct 2016 04:42:05 +0000
To: Jonathan Avila <jon.avila@ssbbartgroup.com>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <CY4PR03MB2438C602172C818B5E4C8E50C8AA0@CY4PR03MB2438.namprd03.prod.outlook.com>
Jon - If it's something sort of incorrect use of attributes, how about failing under 4.1.1 parsing? I believe Andrew has suggested 1.3.1 because it does cover semantic mark-up too. 

Many thanks,

Best regards,
-Vasu
--
Srinivasu Chakravarthula
Lead Accessibility Consultant
Informatica Business Solutions Pvt Ltd.,
Work: +91-80-4020-3760 | Cell: +91 99008 10881
Website | Accessibility Blog | LinkedIn | Twitter

-----Original Message-----
From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
Sent: Thursday, October 27, 2016 7:50 AM
To: w3c-wai-gl@w3.org
Subject: RE: Question: testing for non-unique id values SC 4.1.1

[Jonathan wrote] We ran into a page on the desktop where a left quote was used on an attribute on the HTML element along with a matching straight quote.  A desktop assistive technology couldn't see the page content correctly.   The page looked fine.

[Andrew responded] Fails 4.1.2

{Jonathan responded] How could this be a SC 4.1.2 issue?  It occurred on the HTML element itself which is not a user interface component and is not covered under SC 4.1.2.    it was already discussed on this list that 4.1.2 can only apply to individual components and not the page itself.

[Andrew responded] Sorry, I thought that this was a control for some reason. If this is just page content I’d likely say that it is a 1.3.1 issue.

I am referring to an attribute that was not related to accessibility, I believe it was the class attribute that was located on the root HTML element itself.  It just happened that the quotes used on this class attribute were mismatched and by doing so caused the assistive technology on Windows to not able to render the page contents.  So in my opinion requiring someone to flag this as a SC 1.3.1 issue doesn't seem appropriate.  The information and relationships were all communicated correctly.

e.g. <html class=left  quote something straight quote ... >

[Jonathan wrote] On Android we ran into an issue with TalkBack where a combo box was completely invisible in Firefox.  Turns out the first item in the option list had a blank value and no label attribute.  Blank values must have a label attribute to validate.  Adding the label attribute solved the issue.

[Andrew wrote]  Fails 4.1.2

[Jonathan wrote] I don't think that's intuitive or clear at all.  The intended value is blank and was blank and nbs was used in the textContent of the option.  The fact that the label attribute should have been used doesn't fall under 4.1.2 because adding aria-label to the option element didn't solve the issue -- so even with an accessible name via ARIA the bug still existed.  So it met the criteria of name, role, state, and value.

[Andrew responded] Isn’t the issue that the value isn’t being read?  I might need to see an example to understand why this isn’t 4.1.2.

The issue was that the entire combo box was not seen by Talkback.  That is a person who was blind would not know that a combo box existed on the web page at all.  It was not rendered by the screen reader.  This is the point that we have been trying to make is that when these issues come up it's just not that the value of something is incorrect but whole controls or pages can disappear to the screen reader user.  Very strange issue occurs and they are very tricky to track down.

Jonathan
Received on Thursday, 27 October 2016 04:42:41 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:07 UTC