Last chance for any final editorial comments on Addendum to Best Practices (was Re: Final Version of Addendum)

[Jo Rabin-2]

Hi Kai

Think Francois is off today so I uploaded it for you [1].

[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090923

Reminder to group ref resolution on yesterday's call:

     RESOLUTION: Modulo any final strictly editorial adjustments MWBP WG
     requests [after Thursday] the publication of [BP 1.5] as a WG Note


regds
Jo

----

<<Addendum_to_Mobile_Web_Best_Practices.zip>> Hello all,

I am including the final version of the Addendum.
The only changes made were the resolving of a weird indentation problem.
The effects I had noticed on the last call, such as fully capitalized
elements and oddly formatted acronyms, were only apparent on my laptop.

The ZIP file includes an image that needs to be placed next to the
document itself.

Francois, would you please upload these files?

And thanks to all for their participation.

Thanks
-- Kai

[Charles McCathieNevile-2]

On Wed, 23 Sep 2009 14:56:23 +0200, Jo Rabin <jrabin@...> wrote:

> Hi Kai
>
> Think Francois is off today so I uploaded it for you [1].
>
> [1]  
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090923
>
> Reminder to group ref resolution on yesterday's call:
>
>      RESOLUTION: Modulo any final strictly editorial adjustments MWBP WG
>      requests [after Thursday] the publication of [BP 1.5] as a WG Note

Sorry, I still think the advice (about link decoration in particular, but  
in general) that authors should be responsible for explaining which  
accesskeys are available is harmful. Mobile user agents that support them  
often do the decoration, and in desktop User Agents (or those which are  
sometimes desktop, including Safari and Opera Mini) it is more or less  
critical that the User Agent take this responsibility.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Scheppe, Kai-Dietrich-2]

Hi Chaals,

How do you suggest to deal with the structure and the usage of access keys that, with focus on the nav bar for example, do not necessesarily lend themselves to automated creation?

I am not exactly sure how it would work what you suggest.
I wonder for example, if an author might decide that "4" = "h" should be the access key for "home" on the nav bar, but a user agent may choose some other, not so well suited key.

-- Kai

 

> -----Original Message-----
> From: Charles McCathieNevile [mailto:chaals@...]
> Sent: Wednesday, September 23, 2009 3:32 PM
> To: Jo Rabin; public-bpwg@...
> Subject: Re: Last chance for any final editorial comments on
> Addendum to Best Practices (was Re: Final Version of Addendum)
>
> On Wed, 23 Sep 2009 14:56:23 +0200, Jo Rabin <jrabin@...> wrote:
>
> > Hi Kai
> >
> > Think Francois is off today so I uploaded it for you [1].
> >
> > [1]
> >
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED
> > -mobileOK-pro10-tests-20090923
> >
> > Reminder to group ref resolution on yesterday's call:
> >
> >      RESOLUTION: Modulo any final strictly editorial
> adjustments MWBP WG
> >      requests [after Thursday] the publication of [BP 1.5] as a WG
> > Note
>
> Sorry, I still think the advice (about link decoration in
> particular, but in general) that authors should be
> responsible for explaining which accesskeys are available is
> harmful. Mobile user agents that support them often do the
> decoration, and in desktop User Agents (or those which are
> sometimes desktop, including Safari and Opera Mini) it is
> more or less critical that the User Agent take this responsibility.
>
> cheers
>
> Chaals
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>      je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
>
>

[Charles McCathieNevile-2]

On Wed, 23 Sep 2009 17:30:18 +0200, Scheppe, Kai-Dietrich  
<k.scheppe@...> wrote:

> Hi Chaals,
>
> How do you suggest to deal with the structure and the usage of access  
> keys that, with focus on the nav bar for example, do not necessesarily  
> lend themselves to automated creation?

I'm not sure I am following you...

> I am not exactly sure how it would work what you suggest.
> I wonder for example, if an author might decide that "4" = "h" should be  
> the access key for "home" on the nav bar, but a user agent may choose  
> some other, not so well suited key.

A author might choose "4". But on a touch-screen device, the user might:

- gesture to open access key mode
- select the link/control desired

On another phone, the user may simply press "4"

And on another, the user may use some key to enter accesskey mode, and be  
given a list which has been reordered.

This is something that browsers which are also designed to handle the  
desktop web might naturally do, e.g. to deal with the fact that few phones  
have an "s" key, or that fewer have a "д" key, and that many authors don't  
follow guidelines such as "use only numbers".

Between behaviour necessary for user agents to more effectively render the  
web, and the propensity of authors not to accurately describe how to use  
access keys anyway, it makes no sense to recommend the author describing  
how to use them - any more than it makes sense to recommend that authors  
tell users how to go to the page they were on before.

cheers

Chaals

> -- Kai
>
>
>> -----Original Message-----
>> From: Charles McCathieNevile [mailto:chaals@...]
>> Sent: Wednesday, September 23, 2009 3:32 PM
>> To: Jo Rabin; public-bpwg@...
>> Subject: Re: Last chance for any final editorial comments on
>> Addendum to Best Practices (was Re: Final Version of Addendum)
>>
>> On Wed, 23 Sep 2009 14:56:23 +0200, Jo Rabin <jrabin@...> wrote:
>>
>> > Hi Kai
>> >
>> > Think Francois is off today so I uploaded it for you [1].
>> >
>> > [1]
>> >
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED
>> > -mobileOK-pro10-tests-20090923
>> >
>> > Reminder to group ref resolution on yesterday's call:
>> >
>> >      RESOLUTION: Modulo any final strictly editorial
>> adjustments MWBP WG
>> >      requests [after Thursday] the publication of [BP 1.5] as a WG
>> > Note
>>
>> Sorry, I still think the advice (about link decoration in
>> particular, but in general) that authors should be
>> responsible for explaining which accesskeys are available is
>> harmful. Mobile user agents that support them often do the
>> decoration, and in desktop User Agents (or those which are
>> sometimes desktop, including Safari and Opera Mini) it is
>> more or less critical that the User Agent take this responsibility.
>>
>> cheers
>>
>> Chaals
>>
>> --
>> Charles McCathieNevile  Opera Software, Standards Group
>>      je parle français -- hablo español -- jeg lærer norsk
>> http://my.opera.com/chaals       Try Opera: http://www.opera.com
>>
>>

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Alan Chuter]

Charles McCathieNevile wrote:

> This is something that browsers which are also designed to handle the
> desktop web might naturally do, e.g. to deal with the fact that few
> phones have an "s" key, or that fewer have a "д" key, and that many
> authors don't follow guidelines such as "use only numbers".
>
> Between behaviour necessary for user agents to more effectively render
> the web, and the propensity of authors not to accurately describe how to
> use access keys anyway, it makes no sense to recommend the author
> describing how to use them - any more than it makes sense to recommend
> that authors tell users how to go to the page they were on before.

It might be useful to recommend that rather than defining access keys
and explaining what the definitions are, authors should provide a page
saying that they **don't define them** but pointing to a guide to how
they can work. The MWI could maybe provide such a page to point to,
rather like the page provided by WAI [1] for text size and colours,
which tells people how to use their browsers.

Alan


[1] http://www.w3.org/WAI/changedesign.html

--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: [phone]
achuter@...
http://www.technosite.es

[Charles McCathieNevile-2]

On Mon, 28 Sep 2009 09:11:38 +0200, Alan Chuter <achuter@...>  
wrote:

> Charles McCathieNevile wrote:
>> This is something that browsers which are also designed to handle the  
>> desktop web might naturally do, e.g. to deal with the fact that few  
>> phones have an "s" key, or that fewer have a "д" key, and that many  
>> authors don't follow guidelines such as "use only numbers".
>>  Between behaviour necessary for user agents to more effectively render  
>> the web, and the propensity of authors not to accurately describe how  
>> to use access keys anyway, it makes no sense to recommend the author  
>> describing how to use them - any more than it makes sense to recommend  
>> that authors tell users how to go to the page they were on before.
>
> It might be useful to recommend that rather than defining access keys  
> and explaining what the definitions are, authors should provide a page  
> saying that they **don't define them** but pointing to a guide to how  
> they can work.

Authors *do* define them, but they can be redefined. So we need to be  
careful of the terminology.

> The MWI could maybe provide such a page to point to, rather like the  
> page provided by WAI [1] for text size and colours, which tells people  
> how to use their browsers.

Maybe. This requires a commitment to *maintain* such content, and the BPWG  
at least is not expected to last long enough to make such a commitment  
mean anything at all...

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Scheppe, Kai-Dietrich-2]

Hi,

I would like to proceed here so we can close this document.

On process....
Chaals, what concrete solution do you put forward?

You had mentioned previously
"I therefore suggest removing the text about making the access keys
discoverable as an author responsibility."
Which text exactly?
Or is there some other resolution you suggest?

Are there others, aside from Alan who has already spoken up, with an
opinion on the subject?


On topic....
Chaals, I still don't understand what you are objecting to.

1) we don't mention anywhere that the author does this or must do this.
2) we cover things like being consistant, using primarily navigation
links, etc. rather than who does it
3) You were not sure what I meant when I spoke of associating access
keys with the navbar.
   We say in 3.1 "Typically a "Web site" has common navigation links
that apply to most, or all, pages in the site (a menu bar for example).
Such navigation links should be associated with access keys and the keys
assigned should be the same on all pages. Other frequently accessed
links (such as navigation within a page) may also benefit from being
associated with an access key."



Could you please elaborate on the problem a bit and come up with a
solution that you can propose?
It is rather late to get into a discussion at this level and I really
would like that commentary a few month earlier.
As such I want to finish this as quickly as possible.


-- Kai

[Charles McCathieNevile-2]

On Mon, 28 Sep 2009 11:26:09 +0200, Scheppe, Kai-Dietrich  
<k.scheppe@...> wrote:

> Hi,
>
> I would like to proceed here so we can close this document.
>
> On process....
> Chaals, what concrete solution do you put forward?

Remove the text

[[[

There is no standard way for a content provider to indicate the  
availability of access keys to users of the site.

Common techniques are:
  + Link decoration (put the access key in brackets next to a link e.g. [1]  
Home).
  + Summary page.
  + Listing on a site map.
]]]

 From section 3.1

[...]
> Are there others, aside from Alan who has already spoken up, with an
> opinion on the subject?
>
>
> On topic....
> Chaals, I still don't understand what you are objecting to.
>
> 1) we don't mention anywhere that the author does this or must do this.

No, the text I refer to doesn't match any particular requirement, but  
seems to be strongly conincidentally related to the last test in the  
evaluation list.

In practice, I suggest removing that too since most user agents that  
handle access keys make them available by inspection (sometimes through a  
system function) and those that do not can be considered to be buggy.  
Alternatively, we should explicitly note this issue and point out that as  
part of dealing with common bugs, sites should provide decoration for  
specific known buggy implementations.

...
> It is rather late to get into a discussion at this level and I really
> would like that commentary a few month earlier.

Yeah, I understand that, and I am sorry to start so late in the process.

> As such I want to finish this as quickly as possible.
>
>
> -- Kai
>


--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com