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
Date: Sun, 3 Jul 2022 22:12:23 +0200 [thread overview]
Message-ID: <YsH4Jzd7odZa3mqn@asta-kit.de> (raw)
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
next prev parent reply other threads:[~2022-07-03 20:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 18:18 [PATCH 0/3] Add HTML landmarks Anna Vyalkova
2022-06-28 18:18 ` [PATCH 1/3] Wrap manual header in the "<header>" tag Anna Vyalkova
2022-07-03 17:24 ` Ingo Schwarze
2022-07-03 18:49 ` Anna Vyalkova
2022-07-03 20:12 ` Ingo Schwarze [this message]
2022-07-03 20:51 ` Anna “CyberTailor”
2022-07-05 15:16 ` Ingo Schwarze
2022-07-05 16:15 ` Anna
2022-07-05 18:45 ` Ingo Schwarze
2022-07-05 19:03 ` Anna
2022-07-05 21:39 ` Ingo Schwarze
2022-06-28 18:18 ` [PATCH 2/3] Wrap manual text in the "<main>" tag Anna Vyalkova
2022-07-03 14:41 ` Ingo Schwarze
2022-06-28 18:18 ` [PATCH 3/3] Wrap manual footer in the "<footer>" tag Anna Vyalkova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YsH4Jzd7odZa3mqn@asta-kit.de \
--to=schwarze@usta.de \
--cc=cyber@sysrq.in \
--cc=tech@mandoc.bsd.lv \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).