Re: Context of the main element

Cameron wrote:
> The <main> element is not supposed to be a general purpose container element, there are <section>, <article> and <div> 's for both semantic and unsemantic collections of elements. 

I wasn't asking for it to be general-purpose. It's semantic meaning is very, very specific: it's for the main content. The only detail I was questioning was the scope: why not mark up the main content of an aside, or nav, or article?

> Because it doesn't mean anything in any practical sense, only as "semantic sugar" for css targeting.

In that case, why are header and footer allowed in contexts other than the main body of the document? Are they also only "semantic sugar"? If so, what's wrong with yummy, yummy semantic sugar?

> The point of <main> was to enable non-determinable, nested, skip-to-content navigation where the structure of the page is too complicated for algorithmic determination.
> 
> This is what the ARIA attribute is for, and, the vis-a-vis role of the <main> element. If not implemented in a compatible manner by authors the use case of <main> is negated to the point that it can only be regarded as a non-semantic container element, aka a synonym of <div>.

Well, now I'm confused. Because the nav element fulfils a similar role (skip straight to navigation) but that *is* allowed in multiple contexts and may appear more than once in a single document. But user agents are still able to figure out which nav element is scoped to the document body and therefore corresponds to the ARIA landmark role of "navigation".

By your logic, the nav element should only be used once per document.

> My personal opinion is that users requiring assistance with HTML interaction should be 1st class internet citizens

That is also my personal opinion.

> and as such they require a solution built for purpose and explicitly authored for that mode of interaction.

There I would differ. And historically, when HTML has provided solutions explicitly for that mode of interaction, the results are messy to say the least; see: caption, longdesc …now *there's* a can of worms.

But in any case, I think our personal opinions about the meta-means of enabling accessibility aren't actually relevant to this particular issue.

> It would seem that proponents will not be convinced otherwise until there is real world data so this is a catch-22 situation, but expanding the use cases of <main> only shows the misunderstanding within the specification reading community prior to deployment so it's not looking good.

I think I have understood the spec pretty well, and I'm very much convinced by Steve's argument that a main element is needed in order for the native semantics of HTML to have full parity with ARIA landmark roles. My only quibble is the means by which parsers achieve this. Given that parsers are already matching native semantics to ARIA roles in the cases of nav, header, and footer (where they only do so when those elements are scoped to the body), I'm suggesting that the parsing of the main element could work the same way. As a bonus, we get to use the main element within other sectioning content (just as we get to use header and footer within sectioning content). But parity with ARIA landmark roles is still achieved.

> I honestly can't see the reasoning that thinks that if you can't get people to use role="main" (which is far more semantically flexible anyway) you're somehow going to get everyone to use <main> correctly for the sole purpose of enhancing accessibility.

Well, as you said, until there is real-world data, we wont' know. Personally, I was quite happy to simply use role="main", but I think a lot of developers have a preference for elements over attributes.

Also, isn't the point of the native HTML semantics that, at some future stage, the ARIA landmark roles will no longer be necessary? i.e. they are a stop-gap solution (admittedly a very long-term gap). But as long as there was no native semantic that corresponded with role="main", ARIA roles could never be abandoned completely. Hence, the main element.

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Received on Thursday, 31 January 2013 17:16:57 UTC