Re: ACTION-1440: landmarks section uses "region of page" in prose even though "region" is not a landmark

> On 20/01/2015, at 9:39 am, Matthew King <mattking@us.ibm.com> wrote:
> 
> 
<snip>
> 
> To support the above in HTmL 5, the following mapping is recommended for HTML 5 section: 
> a.        Map section to role presentation if the section element does not have an accessible name. 
> b.        Map section to role region if the section element has an accessible name. 
> 

Done at http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-section <http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-section>.

Jason




> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement 
> Phone: (503) 578-2329, Tie line: 731-7398
> mattking@us.ibm.com 
> 
> 
> 
> From:        Matthew King/Fishkill/IBM 
> To:        WAI Protocols & Formats <public-pfwg@w3.org>, 
> Date:        01/15/2015 09:58 AM 
> Subject:        Re: ACTION-1440: landmarks section uses "region of page" in prose even though "region" is not a landmark 
> 
> 
> Following are two proposals for completing action 1440. Proposal #1 was discussed during the December 18, 2014 <http://www.w3.org/2014/12/18-aria-minutes.html>  ARIA meeting and is revised based on feedback from that meeting. Proposal #2 is a new alternative.
> 
> Summary of proposal #1: 
> 1.        Move alert, grid, list, log, status, and tabpanel up a level to have role section as their superclass.
> 
> 2.        Remove superclass region from article.
> 
> 3.        Change the "Name from" characteristic of role section to "N/A".
> 
> 4.        Modify prose for role region to suggest that assistive technologies should treat a region as a landmark if it has an accessible name.
> 
> 5.        Change the glossary definition of landmark region to more clearly identify what distinguishes landmark regions from other regions.
> 
> 
> Part 1: Move alert, grid, list, log, status, and tabpanel up a level to have role section as their superclass. 
> In addition to landmark, the ARIA 1.0 subclasses of region include alert, article, grid, list, log, status, and tabpanel. This is inconsistent with the description of the region role:
> 
> 
> "A large perceivable section of a web page or document that is important enough to be included in a page summary or table of contents, for example, an area of the page containing live sporting event statistics."
> 
> 
> A list, grid, tabpanel, alert, or status element is not necessarily a large perceivable section of a web page or document that is important enough to be included in a page summary or table of contents. In fact, most of these elements could rarely, if ever, meet such requirements.
> 
> 
> However, they all easily fit within the description of role section:
> 
> 
> “A renderable structural containment unit in a document or application.”
> 
> 
> Part 2: Remove superclass region from article. 
> In ARIA 1.0, article has two superclasses: region and document. But, an article is another element that is often not necessarily a “large perceivable section of a web page or document that is important enough to be included in a page summary or table of contents.” For example, when article is used as the container for comments in a comment thread, a page summary should not list every comment in the thread.
> 
> 
> Removing region as a superclass of article will also serve to further clarify the intent of the region role.
> 
> 
> Part 3: Change the "Name from" characteristic of role section to "N/A". 
> There are three reasons for this change:
> 
> 1.        The “Name from” characteristics of the subclasses of section are not all the same.
> 
> 2.        An abstract role cannot have an accessible name.
> 
> 3.        This would make the specification more consistent. Other similar abstract roles, such as structure, which is the superclass of section, have “Name from” set to “N/A.”
> 
> 
> Note: the introduction of section 5.2.7, Accessible Name Calculation, does not define the meaning of “N/A.” It probably should.
> 
> 
> Part 4: Modify prose for role region to suggest that assistive technologies should treat a region as a landmark if it has an accessible name. 
> There is wide spread adoption by both authors and assistive technologies of the practice of using labeled regions as landmarks. This is because the ARIA 1.0 region description includes the following text:
> 
> 
> “When defining regions of a web page, authors are advised to consider using standard document landmark roles. If the definitions of these regions are inadequate, authors can use the region role and provide the appropriate accessible name.”
> 
> 
> There is general consensus that:
> 
> 1.        This practice is very useful to authors and tremendously beneficial to users. It provides authors with a way of creating landmarks for content that does not fit within one of the already defined landmark types, extending the landmark concept to any kind of content.
> 
> 2.        Because of the industry-wide adoption of this practice, the specification should more clearly state that labeled regions should be treated as landmark regions.
> 
>   
> Add the following text to the region description to more clearly support and further promote consistent adoption of this practice:
> 
> 
> "Assistive technologies and user agents SHOULD provide landmark navigation functionality for elements with role region if the element has an accessible name."
> 
> 
> Consensus has also formed around the suggestion that making the landmark role concrete could provide another way of giving authors a generic landmark role that is more clearly a landmark. However, it is not clear this approach would have significant benefits and some ramifications are potentially problematic.
> 
> 
> First, due to the very substantial number of existing implementations of labeled regions as landmark regions, a concrete landmark role could only serve as a duplicate technique for extending the landmark concept. It would not replace existing practice. Supporting multiple techniques for achieving a single purpose increases complexity. The taskforce should be reluctant to do so without clear need and benefits.
> 
> 
> Second, generic landmark regions without a name should not be allowed because one of the purposes of the name is to supply the information that is missing due to the lack of a purpose-identifying role attribute. When discussed, there were objections to making name required on the landmark role. Such objections would need to be overcome to avoid unlabeled landmarks that would tend to reduce rather than improve usability.
> 
> 
> Part 5: Change the glossary definition of landmark region to more clearly identify what distinguishes landmark regions from other regions. 
> Therefore, this proposal does not include making the landmark role concrete.
> 
> 
> The current definition of landmark is: 
> A type of region on a page to which the user may want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.
> 
> 
> Proposed new definition: 
> A region of a page containing content that is all relevant to a single, author-specified purpose. The purpose of the region is communicated to users by its assigned role, its accessible name, or both. For a region to be a landmark region, its role may be either a subclass of the landmark role or, if an accessible name is provided, it may be the region role.
> 
> 
> The two primary benefits of designating all the landmark regions on a page are that user agents and assistive technologies can:
> 
> 1.        Provide users with efficient navigation to important or frequently used areas of a page, such as the main content, navigation widgets, or search.
> 
> 2.        Provide users with a concise summary of the page. For users with visual or cognitive disabilities, such a summary gives them a way to “quickly glance” at the page to determine what it contains.
> 
> 
> Proposal #2 
> The first 3 parts of proposal #2 are the same as proposal #1. But, proposal #2 provides an alternative approach to supporting labeled, generic, landmark regions. The purpose of this approach is to make the taxonomy even more clear and simple by removing all ambiguity associated with the region role.
> 
> 
> Instead of part 4 and part 5 specified in proposal #1, proposal #2 includes the following:
> 
> 
> 4.        Make region a subclass of landmark and require regions to have an accessible name. This will unambiguously make labeled regions into landmark regions. The abstract landmark role would become a child of section.
> 
> 5.        Map HTML 5 section as follows:
> 
> a.        To role presentation if the section element does not have an accessible name.
> 
> b.        To role region if the section element has an accessible name.
> 
> 6.        Use the new definition of landmark provided in part 5 of proposal #1 but with a small adjustment to the last sentence of the first paragraph so it reads, for a region to be a landmark region, its role must be a subclass of the landmark role.”
> 
> 
> 
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement 
> Phone: (503) 578-2329, Tie line: 731-7398
> mattking@us.ibm.com 
> 
> 
> 
> 
> From:        Matthew King/Fishkill/IBM 
> To:        WAI Protocols & Formats <public-pfwg@w3.org>, 
> Date:        12/01/2014 07:54 PM 
> Subject:        ACTION-1440: landmarks section uses "region of page" in prose even though "region" is not a landmark 
> 
> 
> After today's lengthy discussion <http://www.w3.org/2014/12/01-aria-minutes.html> of action 1440, I gave the issues raised during the call a fresh look. A difficulty facing several of the proposed solutions, which was pointed out several times by James Craig, is that in addition to landmark, other subclasses of region include alert, article, grid, list, log, status, and tabpanel. I propose that this is actually the root of the problem. This is what prevents us from clarifying requirements associated with the region role. 
> 
> Please consider the following. 
> 
> First, the description of region, which was not being fundamentally disputed is: 
> "A large perceivable section of a web page or document, that is important enough to be included in a page summary or table of contents, for example, an area of the page containing live sporting event statistics." 
> 
> Now, ask yourself, is a list, grid, tabpanel, alert, or status element necessarily a large perceivable section of a web page or document, that is important enough to be included in a page summary or table of contents? 
> 
> I believe the answer is clearly "no!" 
> 
> I propose the following changes for ARIA 1.1 to resolve the issues surrounding action 1440. 
> 
> 1. Change the super class of the following roles to be the abstract role section: alert, grid, list, log, status, and tabpanel. 
> 
> 2. Remove region as a superclass of article, leaving article with document as its only superclass. 
> 
> 3. Change the "Name from" characteristic of abstract role section to be "N/A". 
> 
> 4. Change the definition of landmark as follows. 
> Current definition: 
> A type of region on a page to which the user may want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc. 
> Proposed new definition: 
> A region of a page to which the user may want quick access. The region has either a type (role) or label or both that conveys its relevantce to a specific purpose, such as navigating, searching, perusing the primary content, etc. 
> 
> 5. Keep the current landmark role as abstract. Even though we had general agreement that making it concrete may be a good idea, after reconsidering, I think it will create significant problems. Primary reasons: 
> A. a generic landmark role that does not require a label will reduce usability given that the landmark will have neither a clear purpose nor a label. We agreed that if landmark were concrete, it could not require label in order to be exposed as a landmark. 
> B. Making landmark concrete does not benefit current UA and AT implementations that support authors use of labeled regions as generic landmark containers and could create confusion since a labeled region and an unlabeled generic landmark would need to receive equal treatment by UA and AT. 
> C. Given the above proposed definition of landmark and changes to the ontology, we could eliminate the abstract landmark role without losing anything. However, I think this would just create unnecessary work. 
> 
> 6. In the HTML 5 mapping, map HTML section to region only if region has a label. 
> 
> 7. In the core AAM, only expose role region in the platform accessibility APIs if the region has a label. (Note, this is only for role region and not any of its subclasses). 
> 
> 8. Specify accessible name as required for role region and explicitly override that requirement (set it false) for each of the concrete landmark subclass roles. 
> 
> 9. Consider adding the following text to the prose for role region (not sure this is necessary): 
> "Assistive technologies and user agents MAY provide landmark navigation functionality for elements with role region and an accessible name." 
> 
> Taken together, I believe this set of changes will: 
> 1. eliminate all the confusion described in the notes associated with action 1440. 
> 2. Enable legacy implementations to continue working. 
> 3. Continue to give AT vendors the flexibility they have today in UX design. 
> 
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement 
> Phone: (503) 578-2329, Tie line: 731-7398
> mattking@us.ibm.com