From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 19178 invoked from network); 3 Jul 2022 20:12:29 -0000
Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12)
  by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2022 20:12:29 -0000
Received: from fantadrom.bsd.lv (localhost [127.0.0.1])
	by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 01f23c25
	for <ml@inbox.vuxu.org>;
	Sun, 3 Jul 2022 15:12:27 -0500 (EST)
Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82])
	by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 173792d6
	for <tech@mandoc.bsd.lv>;
	Sun, 3 Jul 2022 15:12:26 -0500 (EST)
Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77])
	by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(envelope-from <schwarze@usta.de>)
	id 1o85xB-008My0-83; Sun, 03 Jul 2022 22:12:25 +0200
Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72])
	by hekate.asta.kit.edu with esmtp (Exim 4.94.2)
	(envelope-from <schwarze@usta.de>)
	id 1o85x9-006HT9-8B; Sun, 03 Jul 2022 22:12:23 +0200
Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92)
	(envelope-from <schwarze@usta.de>)
	id 1o85x9-0001TO-KL; Sun, 03 Jul 2022 22:12:23 +0200
Date: Sun, 3 Jul 2022 22:12:23 +0200
From: Ingo Schwarze <schwarze@usta.de>
To: Anna Vyalkova <cyber@sysrq.in>
Cc: tech@mandoc.bsd.lv
Subject: Re: [PATCH 1/3] Wrap manual header in the "<header>" tag
Message-ID: <YsH4Jzd7odZa3mqn@asta-kit.de>
References: <20220628181844.15484-1-cyber@sysrq.in>
 <20220628181844.15484-2-cyber@sysrq.in>
 <YsHQwEk20FQARzFA@asta-kit.de>
 <YsHky81PH7PUI0YF@sysrq.in>
X-Mailinglist: mandoc-tech
Reply-To: tech@mandoc.bsd.lv
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YsHky81PH7PUI0YF@sysrq.in>

Hello Anna,

thank your for your explanations, i think i'm getting closer to
understanding these things.  However, a few details still confuse me:

Anna Vyalkova wrote on Sun, Jul 03, 2022 at 11:49:47PM +0500:
> On 2022-07-03 19:24, Ingo Schwarze wrote:

>> The table in question is clearly page-specific and definitely
>> not the same for all documents on the site.  I really think we
>> should better use the role "doc-pageheader" here and not "banner".

> Yes, this is according to the standards (and to common sense, since
> these sections are not worth assigning landmark roles). However only a
> few screen readers support "doc-pageheader" and "doc-pagefooter" roles,

Ouch.  Is there some way to find out (for a person like me who
lacks experience with assistive technology) which ARIA features are
well-supported across a wide range of assistive technology software
and which tend to be poorly supported or unsupported by some software?

> so an 'aria-label' tag may be needed in addition to avoid confusion:
> 
>   <header role="doc-pageheader" aria-label="Manual header line">

Sure, we can do that.  Still, i am curious how exactly the aria-label
attribute helps in this context.  As far as i understand, the
aria-label is just a name (invisible to the eye) for an HTML element
and doesn't imply anything about document structure.  What difference
does it make for a screen reader whether the aria-label is present or
absent?  Why would a user ever want the words "Manual header line"
read out at them?

>> We might of course consider using <header role="doc-pageheader">,
>> but that would seem unfortunate to me because in the case of man.cgi(8)
>> output, we really need the "banner" role (ideally getting it as the default
>> from a header element) for the site name (e.g. "OpenBSD manual page server")
>> and the search form ("Manual Page Search Parameters").  Using <header>
>> for *that* would perfectly fit the definition of the "banner" role
>> cited above.
>> 
>> As far as i can see, the HTML standard does not prohibit having two
>> <header> elements in a row, for example like this:
>> 
>>   <body>
>>     <header>
>>       <h1><a href="https://www.openbsd.org/">OpenBSD</a>
>>           manual page server</h1>

> If it's only one H1, assigning it a banner role makes little sense as
> it's already reflected in the document hierarchy.

>>       <form action="/" method="get" autocomplete="off" autocapitalize="none">
>>       ...
>>       </form>

> The search form needs to be top-level with role="search" to be
> considered as a landmark:

Yes, the form needs role="search", no doubt about that.

But why does the form need to be top-level in order to be assigned a
landmark role?  So far, i did not find such a requirement in the
WAI-ARIA-1.1 standard.  Did i miss it?  Or is that a constraint due
to some (or all) implementations of assistive technology software?

>From the standards, quite to the contrary, i would expect that
most websites would have a site logo, a site name, and a search form
near the top of each page, and all three of these would go into
a <header> element.  So i would expect that <form role="search">
being on the top level would be the exception rather than the common
case.  What am i missing here?

[ two <header>s as children of the same element ]
> I think it's fine
> 1) in semantic sense (they are still headers and footers, just
>    page-specific ones)
> 2) so we can write "header > table" in CSS

OK, thanks for clarifyong that, so i'll use that if we end up
needing it.

[...]
>> Do you think having two consecutive headers right below <body> would
>> be good here, or what should we do instead?

> This won't happen with my proposal. Either this:
> 
> <form>
> <header>
>
> or this:
> 
> <form>
> <nav> (with <table class="results">)
> <header>

I see.  If we do not wrap the site-oriented information at the top (site name and search form) in a <header> element, then we only have one header.  It seems a bit strange in that case that the header isn't at the top, but maybe that's not a problem?

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv