W3C home > Mailing lists > Public > wai-eo-editors@w3.org > September 2008

Re: Editorial comments on "Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities"

From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
Date: Wed, 10 Sep 2008 07:17:25 +0100
Message-Id: <F217E456-0127-4FF8-BA15-F22C3FC252C0@cs.man.ac.uk>
Cc: wai-eo-editors@w3.org, public-bpwg <public-bpwg@w3.org>
To: Dominique Hazael-Massieux <dom@w3.org>

Hi Dominique,

I just wanted to let you know that I have addressed all your comments  
in the new version <http://www.w3.org/WAI/mobile/experiences-new>. If  
you still think something needs further changes or if I haven't  
addressed any of your comments fully, please let me know.

On 29 Aug 2008, at 14:49, Dominique Hazael-Massieux wrote:

> Hi,
> Reviewing "Shared Web Experiences: Barriers Common to Mobile Device
> Users and People with Disabilities" as of August 29
> http://www.w3.org/WAI/mobile/experiences-new.html
> I noted the following points that might be worth fixing:
> The titles of the common barriers are not worded consistently
> --------------
> Most are purely nominal phrases, but some use full sentences (e.g.
> "Focus (tab) order does not match logical document content sequence");
> for sake of consistency, it would probably be worth making them all
> nominal sentences (e.g. "Inconsistency between focus (tab) order and
> logical document content sequence).
> Most describe problems, but a few are more ambiguous: "Information
> conveyed using color" should probably say "Information conveyed solely
> with color".
> Comment on "Free-text entry"
> --------
> The Mobile Context should probably also mention that the user often
> doesn't have a full keyboard (requiring several key presses for  
> entering
> text), and several distinct text entry modes.
> Comment on "Embedded non-text objects"
> --------
> The Mobile Context should probably also mention that many mobile
> browsers have a much more limited support for non-text objects  
> formats.
> It should also link to
> [OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.
> Comment on "Important information in non-text content"
> --------
> Instead of just "device has no CSS support", say "has no or limited  
> support" (the latter happen much more often than the former).
> Comment on "Information conveyed only using CSS (visual formatting)"
> --------
> Given that CSS is taken into account in "Important information in
> non-text content", this one seems redundant; I suggest either to merge
> them, or to remove the CSS aspects from the previous one.
> Comment on "Interaction and navigation requires mouse"
> --------
> On requiring the mouse, that barrier should mention:
>  * [IMAGE_MAPS] Do not use image maps unless you know the device
> supports them effectively.
> The description of the barrier is actually somewhat broader than its
> title ("wastes time moving through numerous links"); if that's  
> intended,
> there are more best practices that are relevant to that item:
>  * [NAVBAR] Provide only minimal navigation at the top of the page.
>  * [BALANCE] Take into account the trade-off between having too many
> links on a page and asking the user to follow too many links to reach
> what they are looking for.
>  * [ACCESS_KEYS] Assign access keys to links in navigational menus and
> frequently accessed functionality.
> The context should also then mention: "On some mobile devices, the  
> user
> needs to go through each link sequentially" (or something along that
> line).
> Comment on "Special plugin required"
> -------
> "Plugin turned off or not installed;" should probably also mention  
> "not
> available for the user device" since that's again the most likely  
> case.
> Comment on "Link text not descriptive"
> -------
> Should probably also mention "LINK_TARGET_FORMAT".
> The introductory description of the barrier seems to mix mobile- 
> specific
> ("User incurs delay and cost, due to network charges and device
> limitations") and accessibility specific views ("becomes confused or
> disorientated when arrives at inaccessible content"). This probably
> should be put under each context, with a more generic introduction
> ("User does not have enough information to decide to follow a link, or
> gets unusable content when does").
> Comment on "Content blinks, moves, scrolls or auto-updates"
> ------
> It should probably also mention:
>  [IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they
> have an intrinsic size.
> (since its goal is to avoid page re-flowing)
> Typos
> -----
> * In "Multimedia with no captions", "Mobile users often turn off sound
> in public places (trains, hotel lobbies) turn off sound;" has an
> extraneous "turn off sound".
> HTH,
> Dom
Received on Wednesday, 10 September 2008 06:18:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 23 June 2020 20:41:40 UTC