W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2013

RE: Rethinking the necessities of ARIA landmark role "main" and HTML5 <main> element

From: Ian Sharpe <themanxsharpy@gmail.com>
Date: Thu, 4 Apr 2013 16:26:10 +0100
To: "'John Foliot'" <john@foliot.ca>, "'Ian Hickson'" <ian@hixie.ch>, "'Steve Green'" <steve.green@testpartners.co.uk>, 'Léonie Watson' <tink@tink.co.uk>
Cc: <w3c-wai-ig@w3.org>
Message-ID: <9B0C807192DB4F458005F353FEF6705F@sharpyPC>
I've just started another thread on the use of HTML5 structural elements,
ARIA and the user experience which I hope might be helpful in the context of
this discussion.

In short, I currently can't see how any existing techniques or technology
can be applied to provide what I believe is a perfectly reasonable user
experience for somebody using a screen reader to read a blog post with or
without a "main" element.

My premmice is that the current set of structural elements in conjunction
with ARIA simply don't provide enough semantic information to facilitate
continuous reading of a blog post in a way which attempts to mirror how
somebody would read the blog using their sight.

I personally don't feel this mode of operation is too unreasonable to expect
and should be entirely achievable, but I don't believe it is currently
possible which I find a little vexing.

Obviously  I would like to be proved wrong and welcome any suggestions on
how the desired user experience could be achieved using existing techniques
and technology. 

In the context of this thread, I can see the arguments both for and against
the need for a way to identify the "main" content on a web page. My personal
view is that it is better to provide authors with a way to explicitly
specify this region for the reasons others have given previously. But I do
accept that it is not strictly necessary in theory.

What is clear to me is that  the main content, however it might be
determined, does not necessarily only contain "interesting" or "important"
content. It also contains what many people would see as less interesting

I think the really interesting question here is how best to identify this
important and interesting content.

Obviously what is important to one person may not be important to another
and vice versa, but given the current situation, I feel that providing
authors with the ability to identify what they feel is the most important
content for their users would be very helpful, particularly for blogs,
online forums and mail archives for example.

Or failing that, establish some basic rules which could be adopted by user
agents or AT to help them identify potentially less interesting or important
content and give users the ability to enable / disable this feature?


-----Original Message-----
From: John Foliot [mailto:john@foliot.ca] 
Sent: 04 April 2013 15:05
To: 'Ian Hickson'; 'Steve Green'; 'Léonie Watson'
Cc: w3c-wai-ig@w3.org
Subject: RE: Rethinking the necessities of ARIA landmark role "main" and
HTML5 <main> element

Ian Hickson wrote:
> Content is either interesting content or not interesting content.

...or "sometimes interesting", and other times "not so interesting but
important", and other times "new and thus interesting/important" and other
times "been-there-done-that and so not-so interesting/important".

The point is, any content on a web page is not so binary in nature that you
can programmatically determine with any accuracy what is or isn't
interesting - *IN CONTEXT*. 

Only the end user knows what they want, or don't want.

> If you
> mark up all the not interesting content such that it is detectable, 
> then by elimitation, if you skip all such content, the content you 
> reach would be interesting content.

See above.

> It's the exact same thing as the reverse, where you mark up 
> interesting content rather than uninteresting content, and then you 
> skip past content that is not marked as interesting.

Correct, thus <main>. 

The author of the page believes that the content that is in the <main>
region is, on balance, the *most interesting* content. However, all he can
do is 'suggest' that, and allow the end user (and the non-sighted user using
AT) to choose "which" content container is "interesting/important" to them,
at that given time, in context. 

> > How does your solution work if the user has already navigated past
> the
> > main content so they need to navigate backwards? It seems to me that
> a
> > 'skip to main content' feature would work from anywhere on a page 
> > whereas a 'skip past the next n sections' feature may not (maybe it
> can
> > - I can't envision how it would be implemented).
> If there's no more interesting content on the page after the current 
> user position, then the UA can just skip back to the top and advance 
> to the next (first) piece of interesting content.

Which UA? Who/what is implementing this wondrous feature? Is this
functionality on any UA roadmap? Have bugs been filed?

> This is similar to how "find
> on
> this page" interfaces say "returning to top" when they try to search 
> past the last instance of the search term.

Except, what would denote the end of the "interesting" content, especially
given that some content is interesting some of the time, versus not so
interesting other times - same content, different contexts? Are you saying
that "interesting" content ends when "uninteresting content" returns?

> On Wed, 27 Mar 2013, Léonie Watson wrote:
> > From the user's point of view I think this is right. The phrases 
> > "interesting" and "uninteresting" are too subjective to be helpful,
> but
> > essentially a single command that moves focus to the start of the
> main
> > content area of the page is the goal.
> >
> > From an implementation point of view I think this is inefficient.
> It's
> > more reliable and less process intensive to move from A to Z, than 
> > it
> is
> > to move from A, to B, to C, to D and so on until all that remains by
> a
> > process of elimination is Z.
> In practice both are pretty much trivial to implement.
> > So if the goal is to have a single mechanism for moving directly to 
> > a given point on the page, what's the hook the UA uses to make that 
> > possible?
> I think part of the problem with the "mark up the main section" idea 
> is that there's typically not only one piece of interesting content. 
> For example, look at the front page of cnn.com. What one piece of 
> content would you mark up as "main"?

View source, line 81: <div id="cnn_maincntnr">

> How would the user navigate the rest of the page, once they've read 
> that bit?

Really? Nesting containers. Are you really asking that question seriously,
or are you just continuing to be obtuse and refusing to accept the
collective decision of the community?

> With a "skip uninteresting stuff" feature, many more parts of the page 
> are opened up, while still allowing the page authors to denote certain 
> parts as secondary.

<article> - Remember?

Either that, or a screen reader can navigate to the start of <main>, and
just let the reader start reading from that point forward. They can also
tab, or arrow, or bring up contextual dialogs that allows them to navigate
content blocks using the <hX> element.

The point is, with "everything" named (as opposed to everything but the
<main> thing named), navigation schemes can evolve along different tracks.
You are insisting that everyone use the "go past everything else" algorithm
(aka the Scooby Doo algorithm), whereas it appears that in the wild, authors
are already naming their <div>s main (or some equivalent there-of), and so
the community is suggesting that a "go-to" mechanism is more natural and

So let's let the market and tool implementers experiment with both shall we,
and see what evolves. Your continued fighting of <main> is tantamount to
suggesting that your way is the only way, or the better way. We have no
proof of either, and your personal track record on understanding
accessibility issues is hardly exemplary, based upon your years of acrimony
with many accessibility professionals, and self-identified end users of
assistive technology during the HTML5 process.

Received on Thursday, 4 April 2013 15:26:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:44 UTC