RE: Discussion Issues with Landmark ARIA Documentation

Checking back in on this thread.  Is there an action item to update the
documentation?  Anyone else want to discuss?

 

Thanks!

 

Thomas

 

From: Thomas Logan [mailto:tlogan@gmail.com] 
Sent: Monday, November 17, 2008 10:04 AM
To: Al Gilman
Cc: wai-xtech@w3.org
Subject: Re: Discussion Issues with Landmark ARIA Documentation

 

Thanks for the feedback here are my opinions inline

On Wed, Nov 12, 2008 at 6:23 PM, Al Gilman <Alfred.S.Gilman@ieee.org> wrote:

caveat: personal opinions from the hip.



On 10 Nov 2008, at 8:06 AM, Thomas Logan wrote:

I tried implementing ARIA landmarks for codetalks.org to create a real world
example.  Here are a few issues for discussion that came up.

1.       W3C document says landmark contentinfo applies to immediate
ancestor whose role is not presentation.   If you take the code talks page
this is not valid.  The footer is a child of something called globalWrapper.
The contentinfo is actually related to the node with id=content.  I think it
would be more logical and accurate to state that contentinfo corresponds to
content that is marked with role=main.  Is there any other scenario where
the contentinfo would not be referring to the main content on the page?

 

Here's an interaction that we hadn't noted.

If there is an @aria-describedby arc pointing at the @role='contentinfo'
element, then it is about
th source of the @aria-describedby arc.

I do agree it is frequently not the closest ancestor that is not
@role='presentation'.
But @role='main' is too restrictive IMHO.

For a non-main use case, consider photo credits.  These are to me the
essence of contentinfo
and apply to a part of the page that may or may not be main content.


[TLO] Your scenario of photo credits is a perfect example to include in the
Best Practices.  I agree now that linking to @role='main' is too
restrictive.  I think we agree that closest ancestor requirement be removed
from Best Practices.

If aria-described is the proper way to mark up this content then I would
present that this scenario belongs under Relationships rather than
Landmarks.  I anticipate users of assistive technologies querying a
particular element for its relationships to determine where to navigate to
next.  I also picture the user querying their assistive technology for the
common landmarks (navigation, main, search) to navigate around the page.  I
think it is less likely that user will want content-info included in the
landmark list in this case.  Also in an effort to reduce author work, if
aria-describedby is used then is content-info necessary?

 

2.       The Best Practices document says that every region MUST have a
label.  I think contentinfo, search and navigation landmarks should only be
required to be uniquely identified if there is more than one.  This would be
similar to Section 508 1194.22 (i) that requires frames to be titled to
facilitate identification and navigation.  If there is only one landmark
contentinfo, search, or navigation then it is uniquely labeled and navigable
and should not require additional work.

 

+1 this is sympathetic to how we got the <access> element to apply hotkeys
by ID or role.

But we could address this in the spec by making "search" the default value
of @aria-name when @role='search'.

 

[TLO] +1 

 

3.       The Best Practices document shows setting a div tag with a title
attribute to identify the element.   Is this equivalent to providing a
header?  Current testing with JAWS does not show support for reading the
title attribute of a div.

Code example
<div role="complementary" title="weather">

 

This should not be in the Best Practices.  It is a last choice under the
accessible-name determination algorithm.

Unless there are examples of the other markup patters immediately before it
so it is illustrating the last
choice method last.

[TLO] There are no other examples in BP Document.  Suggest action item clean
up Section 4.1 list item 4

 

4.       The BP document also shows using aria-labelledby on an element to
point to the header of a region.  I don't understand why the header content
can't be required to be the first element under the region.

 

It is really bad practice to assume you can have first position in anything.
It absolutely
breaks independent extension in different aspects.  Don't go there.

*If* we can get the ARIA implementation to take on the additional work, it
would make a lot
of sense to define implicit aria-labelledby semantics pointing *at* an <hN>
element.

This is  in effect an rdf:about arc from the <hN> to an enclosing scope just
as with the
'contentinfo' case discussed above.

Until the implementors are willing to take on the extra work, the explicit
@aria-labelledby is
the way to go.

 

[TLO] Is there a place to put this as feature request for implementors?  I
do not think it has to be V1 but its one of those things where browsers
should in most cases be able to reliably determine the information and
reduce work for authors in the general case.
 

 

Code example from document
<p role="main" aria-labelledby="hdr1">
<div role="header" id="hdr1">
Top News Stories
</div>
</p>

Code example from web today
<p role="main">
<h2>Top News Stories</h2>
</p>

Using the existing html markup seems more intuitive.  I'm also not sure why
the example in the document uses <p> tag instead of <div>  What am I
missing?

 

Look at web today in terms of using <p> vs. <div> for a story nugget like
this.  We
should do whatever the world in the wild is doing.

[TLO] Maybe I can use Opera's new MAMA to search for this. 


Al

 

Reference codetalks.org Website
http://wiki.codetalks.org/wiki/index.php/Main_Page
Note you must be logged out of the site to use the landmarks.  Only the
theme for non logged in users currently has role support

Reference ARIA Best Practices
http://www.w3.org/WAI/PF/aria-practices/

 

 

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.4/1793 - Release Date: 11/16/2008
7:58 PM