- From: Christophe Strobbe <strobbe@hdm-stuttgart.de>
- Date: Wed, 27 Nov 2019 19:04:38 +0100
- To: w3c-wai-ig@w3.org
- Message-ID: <cea499bf-d5ff-c0c5-233c-e7fdddd2d77c@hdm-stuttgart.de>
On 21/11/19 20:27, Jonathan Avila wrote:
> 4.1.1 also requires nesting according to the specification.
Yes, and this refers to correct nesting at the *syntactic level*, not to
validation.
E.g. the following would fail:
<p>... <strong>...<em> ... </strong> </em> </p>
The following two code examples would not fail SC 4.1.1, even though
they are invalid according to HTML5:
<a href="doc1.html"><a href="doc2.html">some linktext</a></a>
<a href="doc3.html"><button ...>button text</button></a>
I repeat that it is about correct nesting according to *what the
specification says about syntax*, not about whether element x can be
inside element y according to a DTD, Schema or other validation language.
The formulation was based on XML's concept of wellformedness (which does
not work for HTML 4.01 and HTML5.x), not on SGML or XML validity.
People appear to get this wrong all the time (not just my HCI students).
The problem with applying SC 4.1.1 to HTML5 is that, while XML made a
clear distinction between wellformedness and validity, HTML5 strongly
couples both concepts.
In XML, you can check wellformedness without parsing a DTD or schema,
i.e. you just look at the syntax you get.
In HTML5, this is not possible, because the concept of syntax is depends
in part on the distinction between various types of elements: void
elements must not have an end tag, and you can't know which elements are
void without validation; you can't know which elements have omissible
start or end tags (or both) without validation. (Validation here means
checking a document against the HTML5 schema, which HTML5 describes in
text instead of a formal scheme language such as a DTD.) You can see
this in the syntax section of the HTML5 spec:
https://www.w3.org/TR/html52/syntax.html#writing-html-documents-elements.
The example from Brian Lovely's mail was this:
<ol>
<li>Something</li>
<div>An advertisement</div>
<li>Something else</li>
</ol>
Based on what I wrote above, the syntax can be checked in two ways:
(1) Following XML's approach that separates wellformedness and validity
and that allows syntax checking without or before reading a schema. From
this point of view, the syntax is fine. (Validation would lead to a
different outcome, obviously.)
(XML wellformedness is still explicitly mentioned in Understanding SC
4.1.1: https://www.w3.org/WAI/WCAG21/Understanding/parsing.html. See
also, for example, the statement "any XML parser can perform these
checks for XML-based content" (i.e. any non-validating parser) in an
official response from the WCAG WG from 2007:
https://lists.w3.org/Archives/Public/public-comments-wcag20/2007Nov/0060.html
(last comment). For any element that is not defined in HTML, the
evaluator would need to manually check that the syntax is correct. For
what it's worth, I was an active member of the WCAG WG when that SC was
written.)
(2) Following HTML5's approach that makes syntax dependent on knowing
the markup's schema. In that case, the above code snippet might be
parsed into the following tree:
<ol>
<li>Something</li>
</ol>
<div>An advertisement</div>
<li>Something else</li>
</ol>
This assumes that the parser/browser knows that an ol element must not
contain div elements and that the end tag for ol must not be omitted, so
it is automatically added. The code below the div element has an
orphaned li element that is not part of the first ol, and an orphaned ol
end tag. This is the DOM tree I would expect based on the section
"Misnested tags: <b><p></b></p>" in HTML5.2:
https://www.w3.org/TR/html52/syntax.html#misnested-tags-b-p-b-p.
However, I have also noticed that the DOM tree in Firefox looks as if
the syntax were valid, as if it were perfectly OK to have a div as a
child element of ol:
<ol>
<li>Something</li>
<div>An advertisement</div>
<li>Something else</li>
</ol>
(You can add a CSS rule such as ol * { background-color: yellow; }
to double check that the div is treated as a child of the ol.)
My conclusions from this are the following:
(1) People who claim that the code example with the div inside the ol
violates SC 4.1.1 presumably work with a mental model of syntax that is
closer to HTML5's model but that also includes validation for the
nesting of elements (though not for custom attributes). In other words,
the content models need to be correct.
(2) I have been arguing that it does not violate SC 4.1.1 based on a
mental model of syntax that is based on XML's wellformedness.
(3) I think the Accessibility Guidelines Working Group needs to clarify
whether checking correct syntax includes checking that the content
models of elements are correct. I do not think this was ever the
intended meaning of SC 1.4.1.
Best regards,
Christophe Strobbe
>
> Jonathan
>
> Sent from my iPhone
>
>> On Nov 21, 2019, at 5:58 AM, Christophe Strobbe
>> <strobbe@hdm-stuttgart.de> wrote:
>>
>> On 19/11/19 19:36, Brian Lovely wrote:
>>> Ugh, you mean like:
>>>
>>> <ol>
>>> <li>Something</li>
>>> <div>An advertisement</div>
>>> <li>Something else</li>
>>> </ol>
>>>
>>> That's a violation of WCAG 2.1 SC 4.1.1 Parsing. The ol contains a
>>> non-supported child (the div). Before any accessibility is looked
>>> at, a page must be able to pass an HTML linter with no errors. This
>>> would throw a parent/child error.
>>
>> This example actually doesn't violate SC 4.1.1. That SC is about two
>> things: avoiding duplicate IDs (e.g. to make relationships between
>> label elements and input elements unambiguous) and correct syntax.
>> Having a div as a child of an ol element is a validation issue that
>> goes beyond correct syntax.
>>
>> Best regards,
>>
>> Christophe
>>
>>>
>>> On Tue, Nov 19, 2019 at 1:25 PM Marc Haunschild
>>> <haunschild@mhis.onmicrosoft.de
>>> <mailto:haunschild@mhis.onmicrosoft.de>> wrote:
>>>
>>> Then its a matter of presentation (CSS) not semantics (HTML).
>>>
>>> Respect the separation of concerns principle and things will
>>> become much easier.
>>>
>>> Flex box offers a easy way to make space between two elements
>>> when using margin: auto for example - in this gap you can place
>>> your add - although I still might not understand all aspects of
>>> your particular component, I think I would use something like this
>>>
>>> <ul>
>>> <li>{text}</li>
>>> <li>{text}</li>
>>> <li>{text}</li>
>>> <li>{advertisement}</li>
>>> </ul>
>>>
>>> With order you can rearrange the items and by putting the ad at
>>> the end you don’t interrupt the logical order
>>>
>>> In a future redesign you won't need to touch the HTML - all
>>> changes can be made in the CSS (or SASS/LESS if you prefer to
>>> work with a preprocessor)
>>>
>>> Marc
>>>
>>>> On 19. Nov 2019, at 18:58, Jeana Clark
>>>> <jclark@veritashealth.com <mailto:jclark@veritashealth.com>> wrote:
>>>>
>>>> Hi Patrick - Thanks for your comment.
>>>>
>>>> The problem is we want to put an ad in the middle of a list -
>>>> but not make it a list item. So sometimes if it’s a numbered
>>>> list, we will close the list, insert the ad, and restart the
>>>> list (hence start=“3” on the ol)
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> *Jeana Clark*
>>>> Creative Director
>>>>
>>>> Tel: 847.607.8577
>>>> jclark@veritashealth.com <mailto:jclark@veritashealth.com>
>>>>
>>>>
>>>> Veritas Health, LLC
>>>> <https://urldefense.com/v3/__https://www.veritashealth.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedUd7dO6xA$>
>>>> Inc Best Workplace
>>>>
>>>>
>>>> Spine-health.com
>>>> <https://urldefense.com/v3/__https://www.spine-health.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedXrWZcuvg$> | Arthritis-health.com
>>>> <https://urldefense.com/v3/__https://www.arthritis-health.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedUOrSoztQ$>
>>>> Sports-health.com
>>>> <https://urldefense.com/v3/__https://www.sports-health.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedU5zLI3cA$> | Pain-health.com
>>>> <https://urldefense.com/v3/__https://www.pain-health.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedWnnV_IlQ$>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Nov 19, 2019, at 11:48 AM, Patrick H. Lauke
>>>>> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>>>>>
>>>>> On 19/11/2019 17:12, Jeana Clark wrote:
>>>>>> Sometimes the lists were used as a design solution… writers
>>>>>> wanted to make the content more ’scannable’, and they really
>>>>>> aren’t list items. They’re just bulleted, indented paragraphs
>>>>>> — those I can deal with with redesign.
>>>>>> But sometimes they are ‘lists’ as like, here are 5 treatments
>>>>>> for your lower back pain.. but each ‘list item’ is a thorough
>>>>>> multi-paragraphed description of the treatment, within a list
>>>>>> item.
>>>>>
>>>>> Even in those cases, you should be able to just stick them all
>>>>> in an <li>...</li> without the need for breaking up a list and
>>>>> starting it at a particular number later, unless I'm missing
>>>>> something.
>>>>>
>>>>> P
>>>>> --
>>>>> Patrick H. Lauke
>>>>>
>>>>> www.splintered.co.uk
>>>>> <https://urldefense.com/v3/__http://www.splintered.co.uk/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedUrTQwiLQ$>
>>>>> | https://github.com/patrickhlauke
>>>>> <https://urldefense.com/v3/__https://github.com/patrickhlauke__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedVvmm5Vyg$>
>>>>> http://flickr.com/photos/redux/
>>>>> <https://urldefense.com/v3/__http://flickr.com/photos/redux/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedWx4pJZHw$>
>>>>> | http://redux.deviantart.com
>>>>> <https://urldefense.com/v3/__http://redux.deviantart.com/__;%210Ns9_1dOjwg%21LbjzArpgSoEASxfWUXXXLwkCCFWvrg2bfhy6xx3Bwckv9YpzbWfQuBfgSsBEedW-YlDhJA$>
>>>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> *Brian Lovely*
>>> Capital One Digital Accessibility
>>> 804.389.1064
>>> ------------------------------------------------------------------------
>>>
>>
>> --
>> Christophe Strobbe
>> Akademischer Mitarbeiter
>> Responsive Media Experience Research Group (REMEX)
>> Hochschule der Medien
>> Nobelstraße 10
>> 70569 Stuttgart
>> Tel. +49 711 8923 2749
--
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749
!!!!!!!!
Received on Wednesday, 27 November 2019 18:04:46 UTC