RE: article navigation

Hi Chaals,

>>> By "all AT" do you mean that keyboards should support two layers of  navigation, or just the browsers that provide keyboard interfaces?

Here the need for clearer definitions already starts .. "AT" never means "browser" for me, it is always something needed in addition in real life, Jaws with IE, NVDA with FF and so on.

Unfortunately, the term "user agent" throws screen readers and browsers in the same boat. You can code a browser that is a screen reader as one monolithic "user agent". I know for instance, that Opera offers very good built in keyboard navigation to individual HTML elements, adding screen reader functionality on top would be just a logical step. IBM did that but the reality shows that having screen readers cross-application based offers more flexibility.

So bottom line, I think "AT" is used for extra tools like screen readers and screen magnifiers, but it needs to be checked if we all agree to that before we start discussions based on that.

Regarding the "this is what screen readers should do" discussion I always had the feeling that this is beyond ARIA and subject of another discussion that is not led by the former PF group.

Anyway, you are right that we all have "expectations" what should happen but this also covers development requests for 3rd party products what some guys out there define/expect to be present in those products.

Or, to put it different: I can start to define a list of things I expect YANDEX to do in future, but honestly, what will they think about when confronted with it? Won't this list be invalidated by other priorities, internal backlogs., plans, strategies whatsoever? 

Anyway, I think convincing the screen reader vendors that this or that feature makes sense and here I'm with Matt saying that having article navigation apart from landmark navigation makes sense since for instance for Jaws screen reader this is only a logical extension of its virtual navigation features.

Regards
Stefan

-----Original Message-----
From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Donnerstag, 3. Dezember 2015 02:03
To: Matt King <a11ythinker@gmail.com>; Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: Cynthia Shelly <cyns@microsoft.com>; Richard Schwerdtfeger <schwer@us.ibm.com>; James Craig <jcraig@apple.com>; public-aria@w3.org; PF <public-pfwg@w3.org>
Subject: Re: article navigation

On Thu, 03 Dec 2015 17:24:38 +1000, Schnabel, Stefan  
<stefan.schnabel@sap.com> wrote:

>>>> However, all AT should provide article nav that is separate from  
>>>> landmark nav
>
> +1 !

Here is an example of where we need to clean up our thinking (and a reason  
why I support the principle's behind James' proposal to set ourselves  
better scoping guidelines).

By "all AT" do you mean that keyboards should support two layers of  
navigation, or just the browsers that provide keyboard interfaces? Or  
should zooming activate a special mechanism? Or can it use the same  
mechanism offered by speech input systems? If so, how would that work for  
zoom users who do not rely on speech control?

These questions are phrased a little absurdly, but I want to highlight  
what I think is a very important problem in the way we are designing  
solutions, which is that we make a number of uncommunicated assumptions,  
which are probably not widely shared, but which reduce our ability to make  
good design decisions and seriusly reduce the ability of everyone else to  
review our work and find flaws we may have missed.

More importantly, this results in patchy solutions addressing parts of the  
problem in different ways, but because these get deployed and become  
important to both users and producers, the cost of refactoring  
accessibility solutions to create a more rational, affordable, and more  
broadly effective set of solutions increases, to the point where it is  
prohibitive.

So we don't do that. We stop trying to deal with major issues, and focus  
on patching things around the edge, and forget that we're hiding ever more  
elephants under the carpet.

It seems to me that nobody means "all AT" here, and that nobody has  
considered how it would work if they did mean that.

Both of which are pretty sad conclusions - I'd love them to be proven  
wrong. (And since I used "nobody" twice, they can each be undone by just  
one person…)

cheers

> Sent from my iPad
>
> On 03.12.2015, at 02:17, Matt King  
> <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:
>
> Agree, AT design out of scope... but my $0.02 is that there is no need  
> for a special feed nav mode.
>
> From: Cynthia Shelly [mailto:cyns@microsoft.com]
> Sent: Tuesday, December 1, 2015 10:45 AM
> To: Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>>;  
> 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
>
> Our touch navigation uses modes (headings, items, paragraphs, etc.) with  
> next/previous gestures. I believe the rotor on iOS is similar. One  
> approach would be to have a mode for feed navigation.  Adding modes  
> doesn't work forever, however. When you have too many, switching between  
> them takes too long and can be confusing. Another would be to leverage  
> an existing mode like paragraphs, containers or landmarks.
>
> This is a question of AT UI design though, which seems out of scope for  
> this working group.
>
> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
> Sent: Tuesday, December 1, 2015 10:01 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
>
>
> 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. The user needs to be able jump between  
> articles within a feed without and still be able to navigate the  
> contents of each article. 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

>
>
>
> Rich Schwerdtfeger
>
> [Inactive hide details for James Craig ---11/30/2015 08:56:44 PM---> On  
> Nov 30, 2015, at 11:52 AM, Richard Schwerdtfeger <schwer]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.
>
>
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Thursday, 3 December 2015 10:30:37 UTC