Re: 1.3.1 info and relationships

Hi Marc,

Thanks for your answer and insight!
That (standard formatting of text also communicates structure, namely "this
is plain text") is an interesting interpretation that I haven't seen
before. With that interpretation it would indeed be explicitly demanded by
1.3.1. Very cool. In any case, pragmatically speaking I think we agree on
which situation should fail and which should pass.

Greetings,


*Brian Bors*

[image: Accessibility]

*www.accessibility.nl <https://www.accessibility.nl/>*


Op wo 24 mrt. 2021 om 11:47 schreef Marc Haunschild <
haunschild@mhis.onmicrosoft.de>:

> Sorry Brian,
>
> I haven’t seen that Patrick already wrote everything I wanted to say - and
> better.
>
> Of course you are right in the example you give. If it’s not a header
> semantically it does fail SC 1.3.1 because the "relationships that are
> implied by visual or auditory formatting“ is „this is plain text“.
>
> You will lose this information when changing the presentation format by
> using a user style sheet (it will look like a heading) or a screen reader
> (it will sound like a heading).
>
> So in my opinion this example is even explicitly covered by 1.3.1
>
> Marc
>
>
> Am 24.03.2021 um 11:24 schrieb Brian Bors <b.bors@accessibility.nl>:
>
> Hi Marc,
>
> You are correct. And in such a situation I would not fail the SC. I was
> talking about a situation where:
>
> 1. There is no visual indication its a header and
> 2. it isn't a header semantically speaking but
> 3. it still has a header element.
>
> In that situation I would fail it with SC 1.3.1, despite SC 1.3.1 not
> explicitly saying it should fail.
>
> There is no subjective decision from the auditor if you clearly define
> what a semantic header is and isn't. However WCAG never defined a header so
> there is some small subjectivity in point 2.
>
> Greetings,
>
>
> * Brian Bors *
>
> [image: Accessibility]
>
> *www.accessibility.nl <https://www.accessibility.nl/>*
>
>
> Op wo 24 mrt. 2021 om 11:10 schreef Marc Haunschild <
> haunschild@mhis.onmicrosoft.de>:
>
>> Hi Brian,
>>
>> as a developer I think you are wrong.
>>
>> I write HTMl as a basis for everything on top. I don#t care about the
>> Layout when writing my HTML and try to make the pure HTML completely
>> accessible.
>>
>> Later I put the CSS on top, using the given HTML and adding to the HTML
>> here and there a class or grouping element if necessary for the given
>> layout.
>>
>> This absolutely makes sense - not only from an accessibility point of
>> view - and I might end up with headings, that are not even visible at all.
>> And this is considered as best practice.
>>
>> On the other hand I understand, that you have bad practices in mind. I
>> tsk this from, the word „clutter“. The question is: how a SC can define the
>> border between necessary differences between visible clues from the Layout
>> and too much clutter?
>>
>> I think there is no way (although I'd like to be wrong - suggestions?)
>> and it’s not up to the tester to decide anything in his/hers subjective
>> personal opinion.
>>
>> I’m afraid even a lot of clutter is not a failure, as annoying as it
>> might be…
>>
>> Marc
>>
>>
>>
>> Am 23.03.2021 um 16:06 schrieb Brian Bors <b.bors@accessibility.nl>:
>>
>> Hello Sarah,
>>
>> Strictly speaking 1.3.1 only tells us to make relationships and structure
>> programmatically determinable if they are conveyed through presentation.
>> 1.3.1 doesn't explicitly tell us to make sure we don't convey such
>> relationships and structure in a programmatically determinable way if such
>> relationships and structure is not conveyed through presentation.
>>
>> However most auditors I know (inducing myself) state that if you clutter
>> the page with semantic information in your code that isn't presented
>> through presentation, then it's impossible to actually programmatically
>> determine those relationships and structures that are presented through
>> presentation.
>>
>> So yes. If you would mark up text as a heading while the presentation
>> doesn't communicate that it is a heading I would mark it as a failure. I
>> believe that is both in the spirit and the leter of this SC.
>>
>> Greetings,
>>
>>
>> * Brian Bors *
>>
>> [image: Accessibility]
>>
>> *www.accessibility.nl <https://www.accessibility.nl/>*
>>
>>
>> Op di 23 mrt. 2021 om 15:54 schreef Jonathan Avila <
>> jon.avila@levelaccess.com>:
>>
>>>
>>>    - For example, if text visually appears no different from the
>>>    surrounding text but has been spuriously marked up as a heading or table or
>>>    within a landmark implying it serves a semantic purpose that it does not,
>>>    would this also fail 1.3.1?
>>>
>>>
>>>
>>> I would say yes – because the presentation doesn’t appear to be a data
>>> table yet the markup communicates that – so the two are at odds and the
>>> presentation does not match the semantics.
>>>
>>>
>>>
>>> Jonathan
>>>
>>>
>>>
>>> *From:* Ms J <ms.jflz.woop@gmail.com>
>>> *Sent:* Tuesday, March 23, 2021 10:39 AM
>>> *To:* w3c-wai-ig@w3.org
>>> *Subject:* 1.3.1 info and relationships
>>>
>>>
>>>
>>> *CAUTION:* This email originated from outside of the organization. Do
>>> not click links or open attachments unless you recognize the sender and
>>> know the content is safe.
>>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> Is 1.3.1 specifically focused on the visual presentation of the page or
>>> is it more focused on the semantics in the page?
>>>
>>>
>>>
>>> I can see that visual presentation is often an easy way to provide
>>> semantic context, but there are other ways that the semantics within the
>>> page may be incorrect.
>>>
>>>
>>>
>>> Specifically, the failure F43 which talks about ‘using structural markup
>>> in a way that does not represent relationships in the context’ specifies
>>> that it applies ‘when structural markup is used to achieve a presentational
>>> effect, but indicates relationships that do not exist in the content’
>>>
>>>
>>>
>>> So my question is, does this incorrect structural mark-up have to
>>> ‘achieve a presentational effect’ for this failure to apply? I would have
>>> thought it didn’t, but I wanted to confirm. Could that description be
>>> amended to: ‘when structural markup is used but indicates relationships
>>> that do not exist in the content’
>>>
>>>
>>>
>>> For example, if text visually appears no different from the surrounding
>>> text but has been spuriously marked up as a heading or table or within a
>>> landmark implying it serves a semantic purpose that it does not, would this
>>> also fail 1.3.1?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Sarah
>>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>
>>
>>
>