Difference between revisions of "User:Sfaulkne/main-usecases"

From HTML WG Wiki
Jump to: navigation, search
(Use cases)
(Use cases)
Line 30: Line 30:
 
* Re-use an existing ARIA semantic that currently has to be bolted on by authors and for which where there is already an existing relationship and use with common HTML authoring practices.
 
* Re-use an existing ARIA semantic that currently has to be bolted on by authors and for which where there is already an existing relationship and use with common HTML authoring practices.
 
* Bake in to HTML an existing ARIA role semantic which is [http://www.html5accessibility.com/tests/landmarks.html interoperably supported] across browsers and AT and [http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-aria-landmark-support/ utilised in AT] to provide understanding and utility of an HTML content structure, to the benefit of end users.
 
* Bake in to HTML an existing ARIA role semantic which is [http://www.html5accessibility.com/tests/landmarks.html interoperably supported] across browsers and AT and [http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-aria-landmark-support/ utilised in AT] to provide understanding and utility of an HTML content structure, to the benefit of end users.
 
The following are [http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/ use cases provided by Silvia Pfeiffer]:
 
  
 
==Main use case: accessibility==
 
==Main use case: accessibility==

Revision as of 22:38, 27 November 2012

Rationale and use cases for standardizing a 'main content' HTML feature

This document captures the rationale and use cases for standardizing a feature for identification of the main content section of a web page

Introduction

  • HTML has a pattern of providing an explicit declaritive method for the identification and marking up of significant semantic structures via elements and attributes. Additonal semantics can also be applied by an author to elements in HTML using ARIA attributes.
  • There is an existing pattern in browsers of mapping these elements to roles, states and properties in accessibility APIs
  • There is an emerging pattern in browsers of mapping ARIA semantics to HTML features when roles, states and properties are not already present in an accessibility API.
  • There is an existing pattern of authors defining a distinct container for the main content area of a web page using semantic id values.
    • It has a high correlation with the use of the ARIA role=main which is a semantic marker for the main content area of a web page
    • It has a high correlation with the use of the the id value as a document fragment identifer used as target for 'skip links' to the main content area of a web page.
  • Existing authoring practices for the identification of content structures has previously been used as a reason to add header/footer/article/aside and other elements.
  • Assistive technology have a pattern of using the explicit semantic information exposed by HTML elements via accessibility APIs and/or the DOM to make users aware of the structures and represent their relationship with other structures:

Typical support patterns of HTML elements by screen readers:

  • Identification of an element by role as the user moves through the content.
  • Announcement of the text content of an element.
  • Announcement of the start and end of an element.
  • Change in voice as the content of an element is announced.
  • Announcement of an elements accessible name and/or description
  • Announcement of states and properties.
  • Emission of a beep or other sound when an element with a particulat state or property receives virtual focus.
  • Instructions on how to operate interactive elements such as form controls.
  • Navigation of elements by keyboard and “quick access” lists of a particular elements, list items are linked to each instance of an element on the page.

Use cases

  • Enable users to be able to navigate to and recognise the boundaries of the main content area
  • Enable authors to style the main content area of a page specifically.
  • Enable authors to markup an area of a page as the main content area that with an element that has the semantics built in and discoverable by users.
  • Provide a means for browsers to map role, state and property information to a HTML structure representing a common significant distinct content structure.
  • Re-use an existing ARIA semantic that currently has to be bolted on by authors and for which where there is already an existing relationship and use with common HTML authoring practices.
  • Bake in to HTML an existing ARIA role semantic which is interoperably supported across browsers and AT and utilised in AT to provide understanding and utility of an HTML content structure, to the benefit of end users.

Main use case: accessibility

In my opinion, the main use case for the introduction of <main> is accessibility.

Like any other users, when blind users want to perceive a Web page/application, they need to have a quick means of grasping the content of a page. Since they cannot visually scan the layout and thus determine where the main content is, they use accessibility technology (AT) to find what is known as “landmarks”.

“Landmarks” tell the user what semantic content is on a page: a header (such as a banner), a search box, a navigation menu, some asides (also called complementary content), a footer, …. and the most important part: the main content of the page. It is this main content that a blind user most often wants to skip to directly.

In the days of HTML4, a hidden “skip to content” link at the beginning of the Web page was used as a means to help blind users access the main content.

In the days of ARIA, the aria @role=main enables authors to avoid a hidden link and instead mark the element where the main content begins to allow direct access to the main content. This attribute is supported by AT – in particular screen readers – by making it part of the landmarks that AT can directly skip to.

Both the hidden link and the ARIA @role=main approaches are, however, band aids: they are being used by those of us that make “finished” Web pages accessible by adding specific extra markup.

A world where ARIA is not necessary and where accessibility developers would be out of a job because the normal markup that everyone writes already creates accessible Web sites/applications would be much preferable over the current world of band-aids.

Therefore, to me, the primary use case for a <main> element is to achieve exactly this better world and not require specialized markup to tell a user (or a tool) where the main content on a page starts.

An immediate effect would be that pages that have a <main> element will expose a “main” landmark to blind and vision-impaired users that will enable them to directly access that main content on the page without having to wade through other text on the page. Without a <main> element, this functionality can currently only be provided using heuristics to skip other semantic and structural elements and is for this reason not typically implemented in AT. Other use cases

The <main> element is a semantic element not unlike other new semantic elements such as <header>, <footer>, <aside>, <article>, <nav>, or <section>. Thus, it can also serve other uses where the main content on a Web page/Web application needs to be identified.

Data mining

For data mining of Web content, the identification of the main content is one of the key challenges. Many scholarly articles have been published on this topic. This stackoverflow article references and suggests a multitude of approaches, but the accepted answer says “there’s no way to do this that’s guaranteed to work”. This is because Web pages are inherently complex and many
,

, <iframe> and other elements are used to provide markup for styling, notifications, ads, analytics and other use cases that are necessary to make a Web page complete, but don’t contribute to what a user consumes as semantically rich content. A <main> element will allow authors to pro-actively direct data mining tools to the main content.

Search engines

One particularly important “data mining” tool are search engines. They, too, have a hard time to identify which sections of a Web page are more important than others and employ many heuristics to do so, see e.g. this ACM article. Yet, they still disappoint with poor results pointing to findings of keywords in little relevant sections of a page rather than ranking Web pages higher where the keywords turn up in the main content area. A <main> element would be able to help search engines give text in main content areas a higher weight and prefer them over other areas of the Web page. It would be able to rank different Web pages depending on where on the page the search words are found. The <main> element will be an additional hint that search engines will digest.

Visual focus

On small devices, the display of Web pages designed for Desktop often causes confusion as to where the main content can be found and read, in particular when the text ends up being too small to be readable. It would be nice if browsers on small devices had a functionality (maybe a default setting) where Web pages would start being displayed as zoomed in on the main content. This could alleviate some of the headaches of responsive Web design, where the recommendation is to show high priority content as the first content. Right now this problem is addressed through stylesheets that re-layout the page differently depending on device, but again this is a band-aid solution. Explicit semantic markup of the main content can solve this problem more elegantly.

Styling

Finally, naturally, <main> would also be used to style the main content differently from others. You can e.g. replace a semantically meaningless
with a semantically meaningful <main> where their position is identical. My analysis below shows, that this is not always the case, since oftentimes
is used to group everything together that is not the header – in particular where there are multiple columns. Thus, the ease of styling a <main> element is only a positive side effect and not actually a real use case. It does make it easier, however, to adapt the style of the main content e.g. with media queries.