RE: Relationship to other WCAG in BP2 draft

Alan,
Thanks for the suggestions. I will incorporate them.

Best regards, 
Bryan Sullivan | AT&T

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Alan Chuter
Sent: Monday, February 18, 2008 12:42 AM
To: MWI BPWG Public
Subject: Relationship to other WCAG in BP2 draft


The "1.5 Relationship to other Best Practices and recommendations"
section says "These recommendations follow in the footsteps of the BP1,
and as such are in part derived from the Web Content Accessibility
Guidelines [WCAG]." I'm not convinced of the usefulness of this
statement, which sounds like a bit of name-dropping. I think it causes
more confusion than it clarifies.

There is a new and very much changed and improved version of WCAG
nearing completion. It would be a mistake to base the new BPs in some
way on WCAG 1.0 and ignore many years of work that has been done in the
WCAG WG.

One of the advances in WCAG 2.0 is that it is device-independent.
Translated to MWBP this would mean making the BPs independent of the
DDC. Another is that the WCAG success criteria are testable. While I
wouldn't suggest excluding BP that are untestable, it would be useful to
indicate in the document which ones are testable and likely to be
included in conformance.

The phrase "The WCAG guidelines are supplementary to the Mobile Web Best
Practices" might be better written as "The WCAG guidelines complement
the MWBPs".

best regards,

Alan



On 14/02/2008, Sullivan, Bryan <BS3131@att.com> wrote:
>
> Moving this thread to the public list.
>
> Sean,
> Setting the scope and goals is the critical first task I agree. The 
> draft is consistent with the scope/goals of BP1 as you state them, 
> except for reliance upon a specific device context (basic, or 
> advanced) as the frame.
>
> Here is the scope section. It is clearly focused on the mobile device 
> user experience, and specifically to how web applications (content and
> services) are provided (thus not specifically focused on device 
> capabilities, but the implications of them on the content and services

> that are offered).
>
> ++++
> 1.4 Scope
> These recommendations (BP2) follow in the footsteps of the Mobile Web 
> Best Practices 1.0, (BP1), for which the scope was laid out in "Scope 
> of Mobile Web Best Practices" [Scope] . In summary, BP1 refered 
> primarily to the extension of Web browsing onto mobile devices.
>
> BP2 extends the focus to Web applications generally, which means an 
> application that is accessed and presented via Web technologies. Web 
> applications represent a spectrum of services and content, at the 
> simple end of which are typical Web browsing sites, presented in 
> browsers, which were the focus of BP1. The BP2 focus includes further 
> recommendations for addressing delivery context issues and for use of 
> advanced Web technologies, which apply both to browsers and 
> non-browser web runtime environments.
>
> The recommendations refer to applications as experienced on mobile 
> devices. The recommendations necessarily reflect upon the processes by

> which the applications are developed and delivered, and the nature of 
> the devices and user agents through which they are experienced. 
> However the main focus is upon the applications themselves, including 
> content that is delivered and presented through the applications.
>
> As the goal of the document is to specify Best Practices for delivery 
> to mobile devices, statements that do not have a specific mobile 
> aspect are not included. In particular, many Web Content Accessibility

> [WCAG] guidelines are general to all forms of Web access and are not 
> repeated here unless they have a specific mobile interpretation. 
> Examples of general good practice which have a specific mobile 
> interpretation include "Error Messages" and "Color".
> ++++
>
> The ADC was left off the table in the Nov 07 F2F since as I think, the

> sense was that:
> - it will be difficult to settle on a representative "advanced" device

> since so many new/advanced web technologies have been developed and 
> yet it's still early in terms of their adoption on mobile devices
> - better cost/value will result from addressing a focused set of key 
> issues (based upon BP1 and expanded for new technologies) for web 
> applications, consistent with the BP1 objectives
> (usability/interoperability/efficiency)
>
> The objectives in the current editor's draft are consistent with that 
> focus/scope, and are specifically intended to be addressed for the 
> mobile context (the current terse statements will be expanded per the 
> recommendation outline of BP1).
>
> I will be sending out specific emails to the public list to draw out 
> discussion on the current "goals" section, e.g. the excerpts below 
> (posted here for convenience of the public list readers).
>
> ++++
> 2 Requirements
> This section discusses the requirements of the Mobile Web Best 
> Practice statements in section 5. The statement of requirements is 
> intended to be illustrative rather than exhaustive or complete.
>
> 2.1 Personalization
> Personalization is an important capability in the mobile environment, 
> given the extra effort necessary to interact with services, and the 
> limited output capabilities of mobile devices. Personalization 
> increases the value of content and services to users. However, 
> conventional methods to achieve/maintain personalization (e.g. user 
> input, HTTP redirect, cookies) are problematic given mobile context 
> limitations. The overall goal for personalization in the mobile 
> context is to use user-friendly methods.
>
> 2.2 Security  and privacy
> Security is important to address in the mobile environment, due to 
> more frequent dependence upon personalized information. While this 
> information is essential to increasing service value, its use 
> represents a security and/or privacy risk. The overall goal for 
> security is to protect any personally identifiable information, and 
> especially user identifiers or keys to user identity.
>
> 2.3 User  awareness and control
> Applications should ensure the user is aware of sensitive functions, 
> i.e. that may affect the service experience, and is offered some 
> options for user control.
>
> 2.4 Use of cookies and redirection
> HTTP cookies and redirection fulfill useful purposes in the mobile 
> context. Cookies support statefulness and personalization in browsers,

> two considerations which can simplify the user experience and add 
> value to content and services. Redirect supports server-server 
> interaction via the browser, which is often essential for distributed 
> services which rely upon partitioning of service functions across
different servers.
>
> As compared to their use for web browser applications, cookies and 
> redirect may play less of a role in maintaining statefulness and 
> personalization for for web applications in general.
> Application-specific methods may be used, and may include use of more 
> advanced technologies that are not available to some browsers. 
> However, support for statefulness and personalization will still need 
> to consider similar issues, e.g. state preservation/recovery and
traffic overhead.
> As well, distributed services may still rely upon redirect for web 
> applications.
>
> The overall goal is to set reasonable expectations on the impact for 
> use of cookies and redirect in service delivery to browsers and web 
> applications, and to address alternatives for maintaining statefulness

> and personalization.
>
> 2.5 Conservative use of network traffic Web applications that 
> autonomously interact with network-based services can have a very 
> significant impact on service cost. These costs can be borne by the 
> user and/or network service provider. Users with "bucket"
> or per-KB service plans can find themselves responsible for huge 
> charges. Network service providers can bear these costs for users that

> subscribe to unlimited service plans, and as a result may restrict the

> types of applications available to users with such plans.
>
> The overall goal is that users are informed of the potential impact of

> application operation, and that regardless of the user's service plan,

> applications use network resources conservatively.
>
> 2.6 "One Web"
> - help spread the one web mentality
>
> 2.7 Constraints and Capabilities of the Mobile Context
>
> 2.7.1 Presentation Issues
> As addressed in BP1, presentation issues of mobile devices can also be

> applicable to web applications in general, e.g.
> - variations in page rendering/layout in different devices
> - context/overview constraints due to limited screen size and the 
> limited amount of visible material
> - dependency upon scrolling through material
> - presentation space expense for images and navigation links
> - overall lack of site/content cohesiveness due to fragmentation of 
> display and site structure
>
> However, advanced web browser features and evolving web technologies 
> are adding additional specific issues that need to be addressed in the

> mobile context, including:
> - support for popup windows and layers which can overlap 
> partially/fully
>
> - support for popup menus
> - dynamic changes in screen orientation
> - need for content adaptation (e.g. image resizing/cropping) due to 
> variable presentation space
> - overall usability issues resulting from more complex presentation 
> options
>
> 2.7.2 Interaction Issues
> As addressed in BP1, issues of interaction with applications on mobile

> devices can also be applicable to web applications in general, e.g.
> - limited keypad, e.g. 16-key, leading to difficulty in selecting 
> \characters, and the need for application help in selecting the input 
> character type
> - physical keying difficulty due to small key size
> - form field navigation
> - overall difficulty in entering text impacting usability, e.g. for 
> forms and long URLs
> - no pointing device
> - variations in softkeys for navigation and local application menus
>
> However, evolution of mobile devices is adding additional specific 
> issues that need to be addressed in the mobile context, including:
> - new pointing methods, e.g. touch screens
> - dynamic changes in keyboard layout, e.g. between 16-key, querty, and

> soft keyboards
> - solve the top left navigation problem [need a definintion of what 
> this is, and consideration of whether it is actually testable]
>
> 2.7.3 Delivery Context Variability
> As addressed in BP1, the basic aspects of delivery context in the 
> mobile environment, and how awareness of delivery context relates to 
> the goal of the "one web", also apply to web applications in general.
>
> BP2 extends/expands the discussion for specific delivery context 
> aspects, e.g.:
> - dynamic delivery context property awareness in general, e.g. methods

> of determining current value of properties whether known by the device

> or by the network only
> - issues for specific dynamic delivery context properties, e.g. 
> network bandwidth, roaming, location, network services (e.g.  content 
> transformation
>
> 2.8 Applicability to Non-Browser Web Runtime Environment The focus of 
> the BP2 document is on producing Best Practices that apply to the 
> browser sandbox, while recognising that they may have broader 
> applicability to the Web Runtime (CSS, HTML, Javascript, DOM, 
> Persistent Storage, additional libraries, no browser chrome, cache, 
> etc.), esp Mobile Widgets
>
> 2.9 Toolkit Developer Issues
> Audience of BP2 document will include CPs as well as Ajax and other 
> toolkit developers.
> ++++
>
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: Sean Owen [mailto:srowen@google.com]
> Sent: Thursday, February 14, 2008 7:40 AM
> To: Sullivan, Bryan
> Cc: BPWG
> Subject: Re: Update to BP2 draft
>
> One problem that plagued the early discussions on BP 1.0 was a lack of

> basic agreement on what the goals and non-goals of the BPs were, what 
> was in and out of scope. What emerged after a lot of work was 
> coherent, and one can identify the basic principles of the scope and 
> intent of BP
> 1.0:
>
> - applies to documents/resources, not devices
> - does not prescribe new standards or technologies, and promotes / is 
> consistent with current standards
> - speaks to concerns that are mobile-specific (e.g. there are no best 
> practices on decent error pages since that's true for desktops too)
> - BP 1.0 imagines a baseline device, the DDC, as what sites should 
> target first, and when the device capability is unknown, and makes 
> recommendations based on that device
>
> Now that we have some BP 2.0 text on the table, I think it's worth 
> checking whether we're on the same page. My picture of BP 2.0 was that

> all of the above principles apply, but that we imagine a more advanced

> device, the "ADC", which is something in the ballpark of an iPhone. We

> don't *have* to do this, but it was my understanding, and is my 
> preference, and would likely be less confusing to the public.
>
> With that in mind, reviewing the text written so far, most items seem 
> general and not yet mobile-specific.
>
> Is my understanding wrong, or are we heading in the direction I'm 
> thinking? if not, ah, may we talk about that?
>
> Sean
>
>
>
>


--
Alan Chuter,
Senior Web Accessibility Consultant, Technosite (www.technosite.es)
Researcher, Inredis Project (www.inredis.es/)
Email: achuter@technosite.es
Alternative email: achuter.technosite@yahoo.com
Blogs: www.blogger.com/profile/09119760634682340619

Received on Tuesday, 19 February 2008 08:53:50 UTC