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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 24074 invoked from network); 3 Jul 2022 20:51:09 -0000
Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12)
  by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2022 20:51:09 -0000
Received: from fantadrom.bsd.lv (localhost [127.0.0.1])
	by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 7d640a45
	for <ml@inbox.vuxu.org>;
	Sun, 3 Jul 2022 15:51:07 -0500 (EST)
Received: from sysrq.in (sysrq.in [37.79.202.136])
	by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 9eb7a235
	for <tech@mandoc.bsd.lv>;
	Sun, 3 Jul 2022 15:51:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sysrq.in; s=sysrq.in;
	t=1656881462;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=AopV9xzdUMiLzbYUt7eyeYiq8X4hsRf31TUZ9cERuPo=;
	b=Ab+sklCpmYlN9pC28xIryrA/WLACKVIBpSu5nxjEjOq5KfyiWquwJqJS4vD860paRfu0Wr
	CKxjMFwjNazhWxK+Tcidl2IgOkFid/A9kL5WrofJ2l9zsGpdOhOCZ5gAcP+I9JTvIUCZbG
	EbfKJxAlqbRutKLG7YOgSuSN8uJwwdYPpGGoGsstry8NGqqFjmt8euAvSo76KqOOiPAZXG
	zAcwdtnM+ETvAQKUnXl1vqaEjWfo3dQ7kIQ/foq14mh0JrAnH/fA/g2HdrrWKZD5k1ogjn
	LgvU6kN3ECA50K20nEi/usOLOZf67MzOb4XqoXilqwqm0f19krHJn+jGWpTgSg==
Received: from sysrq.in (localhost [127.0.0.1])
	by sysrq.in (OpenSMTPD) with ESMTPSA id 1f8a5ff2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Sun, 3 Jul 2022 20:51:02 +0000 (UTC)
Date: Mon, 4 Jul 2022 01:51:01 +0500
From: Anna =?utf-8?B?4oCcQ3liZXJUYWlsb3LigJ0=?= <cyber@sysrq.in>
To: Ingo Schwarze <schwarze@usta.de>
Cc: tech@mandoc.bsd.lv
Subject: Re: [PATCH 1/3] Wrap manual header in the "<header>" tag
Message-ID: <YsIBNfFtEggNHnRk@sysrq.in>
References: <20220628181844.15484-1-cyber@sysrq.in>
 <20220628181844.15484-2-cyber@sysrq.in>
 <YsHQwEk20FQARzFA@asta-kit.de>
 <YsHky81PH7PUI0YF@sysrq.in>
 <YsH4Jzd7odZa3mqn@asta-kit.de>
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: <YsH4Jzd7odZa3mqn@asta-kit.de>
Autocrypt: addr=cyber@sysrq.in; prefer-encrypt=mutual; keydata=
	mDMEYIFqhRYJKwYBBAHaRw8BAQdAmXuImZ3E4FYSZevE6xmeyqwBedA5TL3F0mA4nM8Jv5C0J0F
	ubmEg4oCcQ3liZXJUYWlsb3LigJ0gPGN5YmVyQHN5c3JxLmluPoiQBBMWCAA4FiEERA3R5VXjf5
	x8ewz7f6gU36rhAzoFAmCBaoUCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQf6gU36rhA
	zoeCwD/UbmIjoaPHgxAubn/yoHbqtix0p1W8BwVdZSBinqtoc8BAMX19adz5Zx71lYFinFG7Yav
	D4E0jClMEfnYJH2TeG4HuDgEYIFqhRIKKwYBBAGXVQEFAQEHQGL1LYMPZDabnCTPEuyg5QgIlnU
	bKBqoPjp5sNidRZJXAwEIB4h4BBgWCAAgFiEERA3R5VXjf5x8ewz7f6gU36rhAzoFAmCBaoUCGw
	wACgkQf6gU36rhAzpFxwD/Z0QQGqLgBcafYUcHmzYcYxuyazuKWIn3H6OkeFUYtTgBAJmK2E+Yo
	mSMc0Ds93+yNQU0KhN1Ipyp9PiLDSSm8Z4B
User-Agent: Mutt/2.2.6 (2022-06-05)

On 2022-07-03 22:12, Ingo Schwarze wrote:
> 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?

There are incomplete lists:
https://a11ysupport.io/
https://www.powermapper.com/tests/screen-readers/aria/

Key navigation features can be found in the documentation:
https://help.gnome.org/users/orca/stable/commands_structural_navigation.html.en
https://www.nvaccess.org/files/nvda/documentation/userGuide.html#BrowseMode

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

It will say the line before entering the element.

> Why would a user ever want the words "Manual header line" read out at
> them?

To know what to expect (and decide whether to skip or not).

Using a screen reader is like reading through a straw and totally blind
users can't see the whole picture.

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

Yes, there's no such requirement. I misinterpreted it. So wrapping the
form in <header> is fine.

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

Yes, makes sense.

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