Re: 1.3.1 info and relationships

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

[Accessibility]

www.accessibility.nl<https://www.accessibility.nl/>
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


Op wo 24 mrt. 2021 om 11:10 schreef Marc Haunschild <haunschild@mhis.onmicrosoft.de<mailto: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<mailto: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

[Accessibility]

www.accessibility.nl<https://www.accessibility.nl/>
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


Op di 23 mrt. 2021 om 15:54 schreef Jonathan Avila <jon.avila@levelaccess.com<mailto: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<mailto:ms.jflz.woop@gmail.com>>
Sent: Tuesday, March 23, 2021 10:39 AM
To: w3c-wai-ig@w3.org<mailto: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>