E-mail List Archives
Thread: 4.1.1 Parsing > nested elements
Number of posts in this thread: 18 (In chronological order)
From: Fernand van Olphen
Date: Thu, Mar 29 2018 2:59AM
Subject: 4.1.1 Parsing > nested elements
No previous message | Next message →
Success Criterion (SC) 4.1.1 speaks about parsing. It lists the next conditions:
- elements have complete start and end tags
- elements are nested according to their specifications
- elements do not contain duplicate attributes
- any IDs are unique
(except where the specifications allow these features)
According to Technique number 4 the next three techniques must be combined to comply with this SC:
- H74: Ensuring that opening and closing tags are used according to specification AND
- H93: Ensuring that id attributes are unique on a Web page AND
- H94: Ensuring that elements do not contain duplicate attributes
Now I am confused: where is the technique that deals with the condition: elements are nested according to their specifications?
Kind regards,
Fernand van Olphen
Accessibility Advisor
Municipality of the Hague
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Shadi Abou-Zahra
Date: Thu, Mar 29 2018 3:20AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
On 29/03/2018 10:59, Fernand van Olphen wrote:
> Success Criterion (SC) 4.1.1 speaks about parsing. It lists the next conditions:
>
>
> - elements have complete start and end tags
>
> - elements are nested according to their specifications
>
> - elements do not contain duplicate attributes
>
> - any IDs are unique
>
> (except where the specifications allow these features)
>
>
> According to Technique number 4 the next three techniques must be combined to comply with this SC:
>
>
> - H74: Ensuring that opening and closing tags are used according to specification AND
>
> - H93: Ensuring that id attributes are unique on a Web page AND
>
> - H94: Ensuring that elements do not contain duplicate attributes
>
> Now I am confused: where is the technique that deals with the condition: elements are nested according to their specifications?
There is also H75: Ensuring that Web pages are well-formed
- https://www.w3.org/TR/WCAG20-TECHS/H75.html
Also G134 and G192 can be used for full validation of web content.
I found this by using the "How to Meet WCAG 2.0" quick reference guide:
-
https://www.w3.org/WAI/WCAG20/quickref/?showtechniquesA1#ensure-compat-parses
Best,
Shadi
> Kind regards,
>
> Fernand van Olphen
> Accessibility Advisor
> Municipality of the Hague
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
> > > > >
--
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Accessibility Strategy and Technology Specialist
Web Accessibility Initiative (WAI)
World Wide Web Consortium (W3C)
From: Fernand van Olphen
Date: Thu, Mar 29 2018 3:37AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Hi Shadi,
Thanks for the quick response!
Does that mean the following?
1) A web developer codes a website
2) There are incorrect nested elements in his code
2) He picks Technique number 4, the one I mentioned, which is a combination of H74, H93, H94.
3) Because the technique doesn't address the nested elements-issue, his website will pass the Success Criterion.
-----Oorspronkelijk bericht-----
Van: Shadi Abou-Zahra [mailto: = EMAIL ADDRESS REMOVED = ]
Verzonden: donderdag 29 maart 2018 11:20
Aan: WebAIM Discussion List; Fernand van Olphen
Onderwerp: Re: [WebAIM] 4.1.1 Parsing > nested elements
On 29/03/2018 10:59, Fernand van Olphen wrote:
> Success Criterion (SC) 4.1.1 speaks about parsing. It lists the next conditions:
>
>
> - elements have complete start and end tags
>
> - elements are nested according to their specifications
>
> - elements do not contain duplicate attributes
>
> - any IDs are unique
>
> (except where the specifications allow these features)
>
>
> According to Technique number 4 the next three techniques must be combined to comply with this SC:
>
>
> - H74: Ensuring that opening and closing tags are used according to specification AND
>
> - H93: Ensuring that id attributes are unique on a Web page AND
>
> - H94: Ensuring that elements do not contain duplicate attributes
>
> Now I am confused: where is the technique that deals with the condition: elements are nested according to their specifications?
There is also H75: Ensuring that Web pages are well-formed
- https://www.w3.org/TR/WCAG20-TECHS/H75.html
Also G134 and G192 can be used for full validation of web content.
I found this by using the "How to Meet WCAG 2.0" quick reference guide:
-
https://www.w3.org/WAI/WCAG20/quickref/?showtechniquesA1#ensure-compat-parses
Best,
Shadi
> Kind regards,
>
> Fernand van Olphen
> Accessibility Advisor
> Municipality of the Hague
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt
> u op: http://www.denhaag.nl/disclaimer
> > > archives at http://webaim.org/discussion/archives
> >
--
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ Accessibility Strategy and Technology Specialist Web Accessibility Initiative (WAI) World Wide Web Consortium (W3C)
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Steve Faulkner
Date: Thu, Mar 29 2018 3:49AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Passing or failing a success criterion is not the sum of passed techniques.
Techniques only provide guidance on a subset of possible methods to pass.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 29 March 2018 at 10:37, Fernand van Olphen < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi Shadi,
>
> Thanks for the quick response!
>
> Does that mean the following?
>
> 1) A web developer codes a website
> 2) There are incorrect nested elements in his code
> 2) He picks Technique number 4, the one I mentioned, which is a
> combination of H74, H93, H94.
> 3) Because the technique doesn't address the nested elements-issue, his
> website will pass the Success Criterion.
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: Shadi Abou-Zahra [mailto: = EMAIL ADDRESS REMOVED = ]
> Verzonden: donderdag 29 maart 2018 11:20
> Aan: WebAIM Discussion List; Fernand van Olphen
> Onderwerp: Re: [WebAIM] 4.1.1 Parsing > nested elements
>
> On 29/03/2018 10:59, Fernand van Olphen wrote:
> > Success Criterion (SC) 4.1.1 speaks about parsing. It lists the next
> conditions:
> >
> >
> > - elements have complete start and end tags
> >
> > - elements are nested according to their specifications
> >
> > - elements do not contain duplicate attributes
> >
> > - any IDs are unique
> >
> > (except where the specifications allow these features)
> >
> >
> > According to Technique number 4 the next three techniques must be
> combined to comply with this SC:
> >
> >
> > - H74: Ensuring that opening and closing tags are used according
> to specification AND
> >
> > - H93: Ensuring that id attributes are unique on a Web page AND
> >
> > - H94: Ensuring that elements do not contain duplicate attributes
> >
> > Now I am confused: where is the technique that deals with the condition:
> elements are nested according to their specifications?
>
> There is also H75: Ensuring that Web pages are well-formed
> - https://www.w3.org/TR/WCAG20-TECHS/H75.html
>
> Also G134 and G192 can be used for full validation of web content.
>
> I found this by using the "How to Meet WCAG 2.0" quick reference guide:
> -
> https://www.w3.org/WAI/WCAG20/quickref/?showtechniquesA1#
> ensure-compat-parses
>
> Best,
> Shadi
>
>
> > Kind regards,
> >
> > Fernand van Olphen
> > Accessibility Advisor
> > Municipality of the Hague
> > De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt
> > u op: http://www.denhaag.nl/disclaimer
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
> --
> Shadi Abou-Zahra - http://www.w3.org/People/shadi/ Accessibility Strategy
> and Technology Specialist Web Accessibility Initiative (WAI) World Wide Web
> Consortium (W3C)
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> op: http://www.denhaag.nl/disclaimer
> > > > >
From: Steve Faulkner
Date: Thu, Mar 29 2018 3:53AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
This may be helpful:
WCAG 2.0 Parsing Criterion is a PITA
<https://developer.paciellogroup.com/blog/2015/11/wcag-2-0-parsing-criterion-is-a-pita/>
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 29 March 2018 at 10:49, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> Passing or failing a success criterion is not the sum of passed
> techniques. Techniques only provide guidance on a subset of possible
> methods to pass.
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 29 March 2018 at 10:37, Fernand van Olphen <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Shadi,
>>
>> Thanks for the quick response!
>>
>> Does that mean the following?
>>
>> 1) A web developer codes a website
>> 2) There are incorrect nested elements in his code
>> 2) He picks Technique number 4, the one I mentioned, which is a
>> combination of H74, H93, H94.
>> 3) Because the technique doesn't address the nested elements-issue, his
>> website will pass the Success Criterion.
>>
>>
>>
>>
>> -----Oorspronkelijk bericht-----
>> Van: Shadi Abou-Zahra [mailto: = EMAIL ADDRESS REMOVED = ]
>> Verzonden: donderdag 29 maart 2018 11:20
>> Aan: WebAIM Discussion List; Fernand van Olphen
>> Onderwerp: Re: [WebAIM] 4.1.1 Parsing > nested elements
>>
>> On 29/03/2018 10:59, Fernand van Olphen wrote:
>> > Success Criterion (SC) 4.1.1 speaks about parsing. It lists the next
>> conditions:
>> >
>> >
>> > - elements have complete start and end tags
>> >
>> > - elements are nested according to their specifications
>> >
>> > - elements do not contain duplicate attributes
>> >
>> > - any IDs are unique
>> >
>> > (except where the specifications allow these features)
>> >
>> >
>> > According to Technique number 4 the next three techniques must be
>> combined to comply with this SC:
>> >
>> >
>> > - H74: Ensuring that opening and closing tags are used according
>> to specification AND
>> >
>> > - H93: Ensuring that id attributes are unique on a Web page AND
>> >
>> > - H94: Ensuring that elements do not contain duplicate attributes
>> >
>> > Now I am confused: where is the technique that deals with the
>> condition: elements are nested according to their specifications?
>>
>> There is also H75: Ensuring that Web pages are well-formed
>> - https://www.w3.org/TR/WCAG20-TECHS/H75.html
>>
>> Also G134 and G192 can be used for full validation of web content.
>>
>> I found this by using the "How to Meet WCAG 2.0" quick reference guide:
>> -
>> https://www.w3.org/WAI/WCAG20/quickref/?showtechniquesA1#e
>> nsure-compat-parses
>>
>> Best,
>> Shadi
>>
>>
>> > Kind regards,
>> >
>> > Fernand van Olphen
>> > Accessibility Advisor
>> > Municipality of the Hague
>> > De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt
>> > u op: http://www.denhaag.nl/disclaimer
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>>
>> --
>> Shadi Abou-Zahra - http://www.w3.org/People/shadi/ Accessibility
>> Strategy and Technology Specialist Web Accessibility Initiative (WAI) World
>> Wide Web Consortium (W3C)
>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>> op: http://www.denhaag.nl/disclaimer
>> >> >> >> >>
>
>
From: Fernand van Olphen
Date: Thu, Mar 29 2018 4:45AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Hi Steve,
I agree with you that it is a PITA. But I feel that there is a subtle difference between guidance and instruction.
I have to have some ammo if I am auditing a website and in my report I state that SC 4.1.1 is not met because there are incorrect nested elements.
What if the developer is wcag-savvy, reads my report and slaps me back in my face, saying: :
Incorrect nested elements? According to the Sufficient Technique number 4 I do not have to nest elements correctly, because I can pass the SC by a combination of H74, H93 and H94. So, to hell with your incorrect nested elements!
What am I to say to him ? (Besides: you are fired!!!)
Fernand
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Steve Faulkner
Date: Thu, Mar 29 2018 5:04AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
The criterion itself is normative and states:
"elements are nested according to their specifications"
https://www.w3.org/TR/WCAG20/#ensure-compat-parses
If there is a nesting error found when conformance checking the HTML then
from a strict reading it is a failure, it does not need an informative
technique to state that.
But at the same time only a subset of nesting issues will cause
accessibility problems, a <div> inside a <span>, for example, is not an
issue that I consider a blocker.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 29 March 2018 at 11:45, Fernand van Olphen < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi Steve,
>
> I agree with you that it is a PITA. But I feel that there is a subtle
> difference between guidance and instruction.
>
> I have to have some ammo if I am auditing a website and in my report I
> state that SC 4.1.1 is not met because there are incorrect nested elements.
>
> What if the developer is wcag-savvy, reads my report and slaps me back in
> my face, saying: :
> Incorrect nested elements? According to the Sufficient Technique number 4
> I do not have to nest elements correctly, because I can pass the SC by a
> combination of H74, H93 and H94. So, to hell with your incorrect nested
> elements!
>
> What am I to say to him ? (Besides: you are fired!!!)
>
> Fernand
>
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> op: http://www.denhaag.nl/disclaimer
> > > > >
From: Fernand van Olphen
Date: Thu, Mar 29 2018 5:52AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Thanks, Steve!
- Fernand
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: glen walker
Date: Thu, Mar 29 2018 11:28AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Exactly, Steve. I mentioned earlier that when I audit a site, I only point
out parsing issues that could affect accessibility. A <div> in a <span> I
let through, but a <button> in an <a> I flag as an error.
On Thu, Mar 29, 2018 at 5:04 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
wrote:
> The criterion itself is normative and states:
> "elements are nested according to their specifications"
> https://www.w3.org/TR/WCAG20/#ensure-compat-parses
>
> If there is a nesting error found when conformance checking the HTML then
> from a strict reading it is a failure, it does not need an informative
> technique to state that.
>
> But at the same time only a subset of nesting issues will cause
> accessibility problems, a <div> inside a <span>, for example, is not an
> issue that I consider a blocker.
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 29 March 2018 at 11:45, Fernand van Olphen <
> = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi Steve,
> >
> > I agree with you that it is a PITA. But I feel that there is a subtle
> > difference between guidance and instruction.
> >
> > I have to have some ammo if I am auditing a website and in my report I
> > state that SC 4.1.1 is not met because there are incorrect nested
> elements.
> >
> > What if the developer is wcag-savvy, reads my report and slaps me back in
> > my face, saying: :
> > Incorrect nested elements? According to the Sufficient Technique number 4
> > I do not have to nest elements correctly, because I can pass the SC by a
> > combination of H74, H93 and H94. So, to hell with your incorrect nested
> > elements!
> >
> > What am I to say to him ? (Besides: you are fired!!!)
> >
> > Fernand
> >
> > De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> > op: http://www.denhaag.nl/disclaimer
> > > > > > > > > >
> > > > >
From: Jonathan Avila
Date: Thu, Mar 29 2018 8:56PM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
> "elements are nested according to their specifications"
While ARIA isn't specifically called out by this SC and it's not a markup language I personally consider that when ARIA roles are applied to elements then descendant elements roles either explicit or implied should follow as well. For example, if you change an UL to role navigation then the you can't have dangling LI elements without a role like presentation or something else. In my example role navigation shouldn't be applied to UL it should be applied to a div above the UL.
Is this your opinion as well?
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!
From: Steve Faulkner
Date: Fri, Mar 30 2018 3:05PM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Hi Jon,
Use of role=navigation on <ul> is a conformance error
https://www.w3.org/TR/html-aria/#ul
So if you do check your code it will throw an error, for example
https://validator.w3.org/nu/?doc=https%3A%2F%2Fs.codepen.io%2Fstevef%2Fdebug%2FjzYgdJ
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 30 March 2018 at 03:56, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> > "elements are nested according to their specifications"
>
> While ARIA isn't specifically called out by this SC and it's not a markup
> language I personally consider that when ARIA roles are applied to elements
> then descendant elements roles either explicit or implied should follow as
> well. For example, if you change an UL to role navigation then the you
> can't have dangling LI elements without a role like presentation or
> something else. In my example role navigation shouldn't be applied to UL
> it should be applied to a div above the UL.
>
> Is this your opinion as well?
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> See you at CSUN in March!
>
>
From: glen walker
Date: Fri, Mar 30 2018 6:41PM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Going off topic a bit, for an html reference, I prefer the other w3c
document that has Steve's name on it:
https://www.w3.org/TR/html53/
because it's easy to search the left navigation panel. Whatever html
element I'm looking for, I can type the element tag name (without the
brackets), followed by the letter "e" for "elements". So for the <ul>
element, I'd search the page for "ul e". For the <main> element, I'd
search for "main e". (Or you can actually type "element" instead of "e"
but I'm a lazy typer.) This works great when the element name is a common
word, like "table" or "main" or "form", or if the element name is a single
letter or common letter combination found it lots of other words, such as
<a> or <p> or <q> (search for "a e" or "p e" or "q e").
So for the <ul> element, it found the page,
https://www.w3.org/TR/html53/grouping-content.html#the-li-element, which
shows the allowed roles for the <ul> element. Steve had referenced
https://www.w3.org/TR/html-aria/#ul. I just wanted to give another option.
On Fri, Mar 30, 2018 at 3:05 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi Jon,
> Use of role=navigation on <ul> is a conformance error
> https://www.w3.org/TR/html-aria/#ul
>
> So if you do check your code it will throw an error, for example
> https://validator.w3.org/nu/?doc=https%3A%2F%2Fs.codepen.
> io%2Fstevef%2Fdebug%2FjzYgdJ
>
>
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
From: Steve Faulkner
Date: Sat, Mar 31 2018 1:17AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Hi Glen, note that the W3C HTML spec includes the allowed ARIA attributes
for each element, but this is informative, the information is drawn from
https://www.w3.org/TR/html-aria/ <https://www.w3.org/TR/html-aria/#ul>
which is the normative definition for such info.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 31 March 2018 at 01:41, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Going off topic a bit, for an html reference, I prefer the other w3c
> document that has Steve's name on it:
>
> https://www.w3.org/TR/html53/
>
> because it's easy to search the left navigation panel. Whatever html
> element I'm looking for, I can type the element tag name (without the
> brackets), followed by the letter "e" for "elements". So for the <ul>
> element, I'd search the page for "ul e". For the <main> element, I'd
> search for "main e". (Or you can actually type "element" instead of "e"
> but I'm a lazy typer.) This works great when the element name is a common
> word, like "table" or "main" or "form", or if the element name is a single
> letter or common letter combination found it lots of other words, such as
> <a> or <p> or <q> (search for "a e" or "p e" or "q e").
>
> So for the <ul> element, it found the page,
> https://www.w3.org/TR/html53/grouping-content.html#the-li-element, which
> shows the allowed roles for the <ul> element. Steve had referenced
> https://www.w3.org/TR/html-aria/#ul. I just wanted to give another
> option.
>
>
> On Fri, Mar 30, 2018 at 3:05 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi Jon,
> > Use of role=navigation on <ul> is a conformance error
> > https://www.w3.org/TR/html-aria/#ul
> >
> > So if you do check your code it will throw an error, for example
> > https://validator.w3.org/nu/?doc=https%3A%2F%2Fs.codepen.
> > io%2Fstevef%2Fdebug%2FjzYgdJ
> >
> >
> >
> > --
> >
> > Regards
> >
> > SteveF
> > Current Standards Work @W3C
> > <http://www.paciellogroup.com/blog/2015/03/current-
> standards-work-at-w3c/>
> >
> > > > >
From: JP Jamous
Date: Sat, Mar 31 2018 11:52AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Just throwing my 2 cents in here.
I agree with using the role on the Div and not the UL. Especially if we are constructing a dropdown menu. Personally, I prefer for the sake of semantic to use role on a div and stick with children divs to construct the dropdown menu.
I understand that UL is used to create navigation menus, because logically it contains a list of links. So UL is a container for unordered lists of something and using a role on it would overwrite its purpose. Whereas, DIV is used for almost anything. It's main purpose is to divide the pages into various segments. So using DIVs with CSS classes to construct menus and submenus, would be more logical from a HTML semantic prospective. It would not be the easiest way to do it, but that is the reason why in HTML most developers try to create components the easy way. Let's not forget that time is money and in an Agile environment, so many language semantics get violated for the sake of each sprint.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: Jonathan Avila
Date: Sat, Mar 31 2018 6:18PM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
> Use of role=navigation on <ul> is a conformance error
Hi Steve, yes, agreed -- bad choice of example on my part. My question/statement was that when an allowed role is applied to an HTML element or one of it's children then that applied allowed role alters the allowed parent/child elements and allowed roles. Thus the use of the role can break the nesting structure role/implied role and in such cases even if ARIA is applied to only the parent or the child a 4.1.1 violation can occur. That is the nesting structure requirements for 4.1.1 should be based on the calculated role not the element's tag name.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!
From: Steve Faulkner
Date: Sun, Apr 01 2018 4:15AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
> That is the nesting structure requirements for 4.1.1 should be based on
the calculated role not the element's tag name.
yes, agreed
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 1 April 2018 at 01:18, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> > Use of role=navigation on <ul> is a conformance error
>
> Hi Steve, yes, agreed -- bad choice of example on my part. My
> question/statement was that when an allowed role is applied to an HTML
> element or one of it's children then that applied allowed role alters the
> allowed parent/child elements and allowed roles. Thus the use of the role
> can break the nesting structure role/implied role and in such cases even if
> ARIA is applied to only the parent or the child a 4.1.1 violation can
> occur. That is the nesting structure requirements for 4.1.1 should be
> based on the calculated role not the element's tag name.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> See you at CSUN in March!
>
>
From: Fernand van Olphen
Date: Fri, Apr 06 2018 3:21AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | Next message →
Steve, Glen : thanks for your advice!
You both say that not every nesting error is a blocker (like div inside span), but only a subset is (like button in a)
I am curious to know: is there a list of this subset of nesting errors which DO effect accessibility, or if that list is smaller: which DO NOT effect accessibility?
And if not: maybe a good topic for a tweet/article/ etc...to compile such a list?
Regards,
Fernand
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Glen Walker
Date: Fri, Apr 06 2018 10:36AM
Subject: Re: 4.1.1 Parsing > nested elements
← Previous message | No next message
Excellent question. I've never looked for a list. Because of the number of combinations you could potentially create in writing bad html, it might not be possible to enumerate every possible combination that might affect accessibility. For example, having a <ul> that has an immediate child that is *not* a <li> (such as a <span>). It may or may not affect the screen reader, depending on whether the author intended the <span> to be read as an item.
Sent from my iPad
> On Apr 6, 2018, at 3:21 AM, Fernand van Olphen < = EMAIL ADDRESS REMOVED = > wrote:
>
> Steve, Glen : thanks for your advice!
>
> You both say that not every nesting error is a blocker (like div inside span), but only a subset is (like button in a)
>
> I am curious to know: is there a list of this subset of nesting errors which DO effect accessibility, or if that list is smaller: which DO NOT effect accessibility?
> And if not: maybe a good topic for a tweet/article/ etc...to compile such a list?
>
> Regards,
> Fernand
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
> > > >