Re: 1.3.1 info and relationships

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>
>>
>
>