RE: Discussion Issues with Landmark ARIA Documentation

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
blog: http://www.ibm.com/developerworks/blogs/page/schwer

wai-xtech-request@w3.org wrote on 11/24/2008 11:53:20 AM:

> "Thomas Logan" <tlogan@gmail.com>
> Sent by: wai-xtech-request@w3.org
>
> 11/24/2008 11:53 AM
>
> To
>
> <wai-xtech@w3.org>
>
> cc
>
> Subject
>
> 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?
>
Contentinfo, (a footer), can apply to an entire page and not necessarily
just main content.

> 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.
>
aria-describedby should point to the label for the contentinfo section and
not the contentinfo role.

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

> 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?
>
Yes. because the AT will want to navigate to the footer as part of the
entire page anatomy. right?

> 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.
>

That makes sense.

> +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.
>
I agree. This should be logged as an issue. We did not cycle back to this
when
we re-defined the naming process.

> 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.
>
You could but that does not solve the problem of developers using headers
for styling or customizations that
appear between the region and header (could be images).

An implicit relationship avoids mixing content and presentation.

> 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