RE: article navigation

Chaals McCathie Nevile <chaals@yandex-team.ru> wrote:
> 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…)

Chaals, you can cheer up. Normally, when I say "AT" in an unqualified manner, I do mean and think about all AT. Here, I admit to being unusually hasty and I didn't phrase the sentence correctly so AT wasn't properly qualified. I meant to say:

"However, all AT that provide landmark nav should also provide article nav that does not treat articles as landmarks."

My original phrasing made the qualification implicit. I apologize.

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

For this and other reasons, I do not see this thread as evidence that the 1.1 scope has creeped or that the scoping discussions we have had all along have been inadequate. We had a discussion of 1.1 scope at TPAC with respect to the feed role as we did for nearly every 1.1 issue discussed.

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

This may be happening, but I don't see this thread or the development life cycle of the feed role as an example of that. And, examples of the problem you describe are not coming immediately to mind for me.

What I see happening more often is that people put a huge amount of work into careful wording and statements of intent, and it doesn't always get thorough review. That is partly because doing such a thorough review, especially if you are not able to participate daily and in every meeting, is extremely difficult.

We clearly do not want the spec to list all our assumptions and objectives. That happens in meetings, on the list, in issues, in actions, in Bugzilla, and in GitHub. So, if the only thing a person reads is the spec, that person's ability to review and find flaws will definitely be seriously impaired.

Perhaps we need more strictly defined conventions around precisely where the problem statement, objectives, assumptions, and alternatives considered are documented. All of that has happened with the feed role, but not in one place. My intent, as someone who appreciates thorough documentation,  has been to summarize that in issue 633, which  seemed to be the seed of all related changes and then reference everything back to that. But, developing that paper trail that pulls it altogether keeps being pushed out due to more pressing actions.

Matt King

-----Original Message-----
From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Wednesday, December 2, 2015 5:03 PM
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 17:08:34 UTC