RE: article navigation

At TPAC we explicitly punted the more general approaches I had raised to 2.0
but have designed and worded 1.1 in a way that keeps possible future
directions in mind.

 

From: Cynthia Shelly [mailto:cyns@microsoft.com] 
Sent: Wednesday, December 2, 2015 3:30 PM
To: Richard Schwerdtfeger <schwer@us.ibm.com>; James Craig
<jcraig@apple.com>
Cc: public-aria@w3.org; PF <public-pfwg@w3.org>
Subject: RE: article navigation

 

There are actually a lot of lists that are infinite or long enough to have
the same user experience issues.

 

Email inbox 

Social media feed

Database query results

Search results

Calendar in agenda view (list of appointments going off into time)

Newsfeed (e.g. flipboard)

A blog with a lot of posts

 

There are some related scenarios that are infinite/huge but have slightly
different behavior, that we've been talking about as part of script-based
accessibility:

 

Spreadsheet

Large document (word, pdf): pages, long bullet list, outline

Presentation slides (powerpoint): slides

                

I'm starting to think that we need a general solution to this problem. Maybe
a role can cover the first group, but I'm not sure feed is the right name
for it. Many of these have article children, but not all do, and there are
likely other infinite lists that I haven't thought of, with different kinds
of children.

 

 

 

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Wednesday, December 2, 2015 9:07 AM
To: James Craig <jcraig@apple.com <mailto:jcraig@apple.com> >
Cc: public-aria@w3.org <mailto:public-aria@w3.org> ; PF <public-pfwg@w3.org
<mailto:public-pfwg@w3.org> >
Subject: Re: article navigation

 

As was stated before lists are navigated using a standard input mechanism.
These are static. Also, lists don't typically have an infinite stream of
list items which a feed would have. Tabbing does not work either as you end
up landing on embedded links. A feed should also have additional input
mechanisms to go home or end. 

I don't agree that an article should ever be a landmark. I don't want to
bring up a list of a 1000 landmarks on a page. This is why I have always
argued about having them being a landmark. In the case of a Facebook or
Twitter Feed the list could be enormous. 

Rich


Rich Schwerdtfeger

James Craig ---12/01/2015 04:06:44 PM---> On Dec 1, 2015, at 10:01 AM,
Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote:
>

From: James Craig <jcraig@apple.com <mailto:jcraig@apple.com> >
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-aria@w3.org <mailto:public-aria@w3.org> , PF <public-pfwg@w3.org
<mailto:public-pfwg@w3.org> >
Date: 12/01/2015 04:06 PM
Subject: Re: article navigation

  _____  

 

On Dec 1, 2015, at 10:01 AM, Richard Schwerdtfeger <schwer@us.ibm.com
<mailto:schwer@us.ibm.com> > wrote:

So, one of the things we have added is a "feed" role that takes a list of
articles. So, at least in this instance you know that articles within a feed
are part of the feed. 


Why does the user need to care about that? Seems like main > article or list
> listitem would suffice. 


The user needs to be able jump between articles within a feed without and
still be able to navigate the contents of each article. 


This is a case for making article a landmark, whether or not it's in another
type of container role. 


Facebook will be implementing for its infinite feeds. They implemented these
"J" and "k" keyboard commands to navigate among the articles (you can try it
on Facebook). This won't fly in a mobile touch device so I was hoping we
could leverage something you were doing for articles. ... however if you
have suggestions about how that could be done on a mobile device that would
be great. 

I have a product team who can already make use of feeds. I am not sure if
you looked at it yet but here it is:

 <http://www.w3.org/TR/wai-aria-1.1/#feed>
http://www.w3.org/TR/wai-aria-1.1/#feed


I looked at it. I don't see a compelling case for feed > article over just
loose articles in the page or main...

James 



Rich Schwerdtfeger

James Craig ---11/30/2015 08:56:44 PM---> On Nov 30, 2015, at 11:52 AM,
Richard Schwerdtfeger < <mailto:schwer@us.ibm.com> schwer@us.ibm.com> wrote:
>

From: James Craig < <mailto:jcraig@apple.com> jcraig@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: PF < <mailto:public-pfwg@w3.org> public-pfwg@w3.org>,
<mailto:public-aria@w3.org> public-aria@w3.org
Date: 11/30/2015 08:56 PM
Subject: Re: article navigation 

  _____  





> On Nov 30, 2015, at 11:52 AM, Richard Schwerdtfeger <
<mailto:schwer@us.ibm.com> schwer@us.ibm.com> wrote:
> 
> Hi James, 
> 
> Does VoiceOver have a gesture navigation capability to move among articles
on iOS?

No. VO has a rotor for landmarks, but article is not a landmark. 

Also, are you referring to ARIA's article role, or HTML's <article> element?
IIRC, there was also some concern that the <article> element was being
overused, and a direct 1:1 mapping to the ARIA article role would result in
false positives. We'd need heuristics in the engines to snuff of the
extraneous articles like we have for layout tables and listitis overuse.

James

PS. "feed" seems a out-of-scope for a 1.1 criteria, does it not? Why is a
list of articles in a feed more or less semantic than a list of article
outside a feed? Does the end user need to know about the difference? If not,
cut it.