- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Fri, 30 Sep 2016 10:56:52 -0400
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
SC 4.1.1 is even more important today as compliance helps to ensure compatibility and robustness, given it is not always possible to test all browser / AT combos. I fully agree with Jonathan that issues are manifested sometimes when nesting is not valid or tags are not closed or ids are repeated ... i.e. items covered by 4.1.1. In previous posts on the topic of SC 4.1.1 (on this list and here at Deque) I have stressed the importance of doing a test for 4.1.1 before doing other accessibility testing. What I asked at the outset and proposed based on the first few responses does not weaken the SC or its intent but is done with a hope to clearly delineate what is within the scope of accessibility testing on the topic of non-unique id values. Id values repeated in hidden content not referenced by ARIA may be covered by testing for functionality or code quality ... not accessibility testing. I disagree with the assertion, "I think that it is a reasonable interpretation of 4.1.1 that what matters for HTML is that the source markup doesn’t have duplicate id attribute values". >>If I implement content using javascript to create a useful DOM tree, am I using markup? JS is used to dynamically alter content implemented using markup languages and not in a vacuum independently IMO. JS adds / deletes elements or properties / attribute values of content using markup languages. I wonder why change to normative content is needed. By limiting the scope of tests to four things, SC 4.1.1 reads fine now. Thanks, Sailesh Panchang On 9/30/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > Ø It doesn’t seem to be a stretch to count JavaScript created markup or DOM > manipulation as part of “markup languages”. > > I agree. I believe the intent of that clause was to specify which > technologies were in or out and not to say that DOM manipulation wasn’t > covered. I agree some things likely won’t be an issue in situations where > content is added to the DOM dynamically but the SC would still apply IMO. > > > Ø If the APIs are the official way to do things, the usefulness of 4.1.1 > has reduced as anything the browsers don’t interpret should be apparent to > everyone, not just people using AT. > > I disagree because the visual rendering engine of the browser is likely > separate from the DOM to accessibility API bridge and the accessibility API > is likely to contain issues that aren’t rutinely found by the browser QA > teams. Unless the browsers start implementing some sort of accessibility > test harness and really be looking for them. The API is also susceptable to > issues IMO when it’s built/updated based on bad structure. How does the DOM > to API bridge handle bad markup and what decisions does it make in order to > compenstate for incorrect markup/DOM structure? > > Jonathan Avila > Chief Accessibility Officer > SSB BART Group > jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com> > 703.637.8957 (Office) > > Visit us online: Website<http://www.ssbbartgroup.com/> | > Twitter<https://twitter.com/SSBBARTGroup> | > Facebook<https://www.facebook.com/ssbbartgroup> | > Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | > Blog<http://www.ssbbartgroup.com/blog/> > Check out our Digital Accessibility > Webinars!<http://www.ssbbartgroup.com/webinars/> > > From: Alastair Campbell [mailto:acampbell@nomensa.com] > Sent: Friday, September 30, 2016 4:03 AM > To: w3c-wai-gl@w3.org > Subject: Re: Question: testing for non-unique id values SC 4.1.1 > > Andrew asked: >> If I implement content using javascript to create a useful DOM tree, am I >> using markup? > > That’s a good point, and I would hope the answer is yes otherwise there is a > whole category of websites not covered. (Assuming we want any to be covered > by 4.1.1, the answer should be yes.) > > It doesn’t seem to be a stretch to count JavaScript created markup or DOM > manipulation as part of “markup languages”. > > I think there has been a trend in recent years for AT to use the > accessibility APIs rather than do their own interpretation. Jaws was the > obvious one that did its own interpretation but I think it is using the APIs > now… Can anyone confirm? Are there others that do their own interpretation? > > If the APIs are the official way to do things, the usefulness of 4.1.1 has > reduced as anything the browsers don’t interpret should be apparent to > everyone, not just people using AT. > > >> Also, what is “markup content”? :) > > You (probably) jest, but “markup” does appear to be an omission from the > WCAG 2 glossary! > > -Alastair >
Received on Friday, 30 September 2016 14:57:22 UTC