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