Re: article navigation

I agree with Cynthia that "feed" is not the best name.

What is the core problem you're try to solve? Ease of navigation for Assistive Technology? Doesn't the mainstream full keyboard access user also experience this problem? Why does an ARIA-specific solution make sense over a native solution? I don't see the need for a new role if this is just about ease of navigation.

James

PS. Sounds like a great use of the "Next" navigation event from IndieUI or an equivalent API. ;-) Maybe the next/prev article navigation proposal should be aimed at WebApps? (Cc Chaals) 


> On Dec 2, 2015, at 3:30 PM, Cynthia Shelly <cyns@microsoft.com> wrote:
> 
> 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 <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 <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: PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org>>, public-aria@w3.org <mailto: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 <schwer@us.ibm.com <mailto: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.
>