Application Foundations/UsabilityAndAccessibility

Usability, Accessibility, Internationalization

Goals across these three areas

Clarify goals in each area relative to Application Foundations
Map technologies for each area to Application Foundations
Identify staff and WG resource gaps
Recruit people and pursue resources to fill gaps
Report to Membership on status/progress of work in the area

Milestones across these three areas

February 2: Establish any common goals across these three areas
February 16: Each area start outreach
March 2: Prioritize bottlenecks and application targets for each of these three areas
March 16: Map technologies and strategies to Web technologies
March 30: Proposed prioritization of actions for staff
April 13: Suggestions for additional resources investment per area
April 20: Report on progress due for AC meeting
May 5: AC meeting starts

Accessibility

Relevant Accessibility Technologies

Accessible Rich Internet Applications (ARIA) 1.0, 1.1
Indie UI
Accessibility APIs
Web Technology Accessibility Guidelines (WTAG)
Media Accessibility User Requirements (MAUR)
[expand this list]

Accessibility Goals

Develop WAI2020 Framework including modular/flexible plan for accessibility guidance for AF & Verticals
- Two public input discussions at CSUN, went well, additional in planning stage
Improve resources and mechanisms for coordination with expanded W3C scope of technical areas
- WTAG progress, interest, engagement
Recruit accessibility experts interested in working in new areas of AF & Verticals
- One presentation so far, needs refinement, need to put online
Develop a use-case and user-scenario library
- Progress on interest, part of WAI2020
Expand testing resources for accessibility
- Progress on potential contributions of testing resources
Create map of advanced accessibility architecture relative to OWP & AF
- Further discussions, interest

Accessibility Milestones

February 2: Draft plan for WAI2020 Framework Discussion at CSUN 2015; announcements; initial outreach
February 16: Develop outreach plan for more accessibility experts for AF & Verticals
March 2: WAI2020 Framework discussion starts
March 16: Summary of CSUN WAI2020 Framework discussion & updated plan for G3ICT WAI2020 & AccessU
March 30: Recruitment-into-verticals presentation available
April 13: Summary of progress on testing resources
April 20: Draft of Web Accessibility Ecosystem architecture
May 5: Drafts on remaining except use case repository

Internationalization

Application Foundation Progress

The Internationalization Activity primarily supports development of application foundations by working with W3C Working Groups to ensure that features needed for international users are taken into account. There is good traction with the developers in the Working Groups, but the work is demanding and highly varied, and it is always hard to find people who are able and interested in the work of reviewing specs and guiding developers to make well-internationalized specifications.

Initiatives are under way to intersect with specification development work as early as possible, to relieve some of the pressure and trauma of discovering internationalization issues late in the day, but also work is under way to capture information in the form of documented lists of do's and don'ts, so that the Internationalization Working Group becomes less of a bottleneck for this guidance. See Internationalization Best Practices for Spec Developers (and it's task-based, quick-access page), as well as the documents listed below.

The Internationalization WG has to be flexible and prioritize issues as they arise, but major topics that are directly applicable to the developers of applications and need attention in the near and medium term include the following:

Choice and use of character encodings. This is a fairly well understood problem, and we already have the document Character Model for the World Wide Web: Fundamentals, but the Encoding specification will strengthen the commitment to UTF-8, reduce use of legacy encodings to a safer and more interoperable subset, and add APIs. The browser implementers are generally implementing the spec, but we are in need help to develop tests.
String matching and searching. A recurrent issue, this is much less well understood and is important for things like range selectors, annotations, identifier matching, and the like. We are assembling guidelines in Character Model for the World Wide Web: String Matching and Searching.
Handling of local formats, time zones, and locales. This area is still poorly understood but is becoming particularly important for applications such as form validation and input, CSV data management, web payments, etc. We have begun work on Language Tags and Locale Identifiers, but the area still needs a fair amount of research.

The Internationalization Activity is also providing resources which can support application developers.

There are significant gaps in support for display of non-Latin scripts. These are critical issues for applications using technologies such as CSS, SVG or Digital Publications, but until now there has been very little information available about requirements for text justification, line breaking, non-Latin emphasis, and many other typographic features needed to make the Web feel locally relevant and useable.

The Internationalization Activity has begun providing that information. We began with Japanese, and are now working on Korean, Chinese, and Devanagari requirements. There is still much work to do, however. Encouragingly, we have been approached by people who want to develop requirements for Arabic, Ethiopic, Mongolian, Tibetan, and Uighur scripts, and are preparing the way for that. (These initiatives also bring new people from user communities around the world into contact with the W3C.)

Once we have the requirements, we need to identify gaps and close them. In particular, the Internationalization WG is currently working with developers on:

Bidirectional text support. We recently helped the HTML5 developers add important features to improve support for the many millions of people using right-to-left scripts. We now need to address more deeply the needs of bidi support in plain text environments, such as WebVTT, CSV, JSON, etc.
Vertical text and ruby. These features were highlighted as pressing needs for Asian digital publications in a recent W3C workshop. The i18n Activity helped create a new model in HTML that has now been largely implemented in browsers, but ruby styling is still in development (although Firefox now has very good support for this, from a base of no ruby support at all just a few weeks ago.) Vertical text support in CSS has been many years in development, and there is now increased pressure to finally produce a solution. This has further to go than ruby, but work is in progress.
Other typographic requirements. The Activity aims to support CSS in particular and other working groups by pulling together pointers to most aspects of non-Latin typography in Improving text layout and typography on the Web and in eBooks, and compiling information until such time as it can be added to a larger layout requirements effort. This will serve as a resource for browser implementers and application developers.

As part of its work on identifying and closing gaps in features required for international deployment of W3C technologies, the Internationalization Activity is also developing internationalization-related tests and compiling the results of those tests for major browsers. The tests are being used by all major browsers (and are pushed to the Web Platform and CSS test repos), and the results regularly prompt implementers to address gaps in their international feature support. They are also a useful resource for all Web application developers.

While the work of the Internationalization Activity is well known in W3C Working Groups and regularly communicated at major internationalization-related gatherings (such as the Unicode Conference), and although published work is announced through the W3C home page, twitter accounts, etc., we don't really have information about how well known the work is among the general developer population. It may be helpful to identify new ways of communicating the work as long as they don't significantly stretch the already thin resources of the personnel involved in internationalization at the W3C.

Key activity areas of i18n WG

The following notes cover the work of the i18n Activity in general.

reviews, discussion & advice
developer guidelines
requirements development
gap analysis & bridging
test development
education & outreach
tracking collateral developments

Goals

Reviews, discussion & advice

continuous support of OWP development through review, discussion and advice with W3C Working Groups

Developer guidelines

produce guidelines for OWP spec developers about i18n issues, so that they can integrate i18n considerations into their work as early as possible, and lessen the requirement for involvement of i18n personnel
recycle experience in reviews into useful guidance
facilitate the new process by enabling a degree of self-review, and reduce the likelihood of big surprises near the end of development

Requirements

develop better understanding of requirements for support of non-Latin scripts on the Web and in eBooks
provide support, especially to CSS and Digital Publications work, on typographic and layout requirements on the Web and in eBooks, so that the needs of communities around the world are provided for
reach out to communities around the world that don't have such an active voice at W3C and include them

Gap analysis & bridging

do gap analysis of needs of the multilingual web as described by user requirements and support provided by key technologies of the OWP (esp CSS, HTML) and support initiatives to bridge those gaps
do gap analysis of needs for multilingual web content creation, including starting from monolingual content and doing translation (esp ITS2, XLIFF) and support initiatives to bridge those gaps

Tests

develop tests for i18n features being developed as part of the OWP and summarise current support by browsers and ebooks
support development of i18n features in OWP Working Groups by highlighting issues and successes, and clarifying status in implementation of i18n features of specifications, esp. CSS and HTML
contribute tests to W3C test suites
provide support for education and outreach information

Education & outreach

provide education and tools for users of OWP about how to apply i18n features

Tracking collateral developments

track other factors than those relating to the OWP technologies that affect the accessibility of OWP features, and work with other organizations or groups to assist in resolving those issues where needed

Current focus

Useful tracking documents

Goals (Usability)

There are three kinds of usability: for the Web developer, for the user and for the implementer.

(See also an old essay of mine [BB]: What is a good standard?)

Usability for the implementer

Specifications are easy to read
Specifications are consistent with each other in style, structure and vocabulary
Specifications have clear examples
Specifications explain the necessary algorithms & data structures if they aren't obvious
Specifications have a long life: learning new standards every few years is costly
The Web Platform is modular: a team of implementers can each work on different aspects, and independent programs can each implement a part and work together (useful metaphors: the Unix pipe line, the mailcap system, plugin architectures)
Test suites are comprehensive
Test suites are easy to use (automated, if possible)
Individual tests are easy to read, to make it easier to determine why a test failed

Usability for the Web developer

There is consistency among the various formal languages and APIs
Common tasks need little code, uncommon things are still possible
Hard things (i.e., hard for most developers), such as i18n, device independence, accessibility, handling network errors, privacy and security, are, as far as possible, automatic and/or enforced
There is good documentation (in addition to the specifications)
There are good tools (validators, debuggers, simulators, preprocessors, IDEs)
There exist good documentation and good tools that are free (even if there also better ones that cost money)
There are both simple and advanced languages/APIs (because there are experienced developers, but also occasional and beginning ones)
Versions of a language or API are backwards compatible (because at any time on the Web there is a mixture of old and new applications and old and new implementations), or, stated differently: if new features are needed and cannot be added without breaking backwards compatibility, a new technology with a new name (i.e., a new MIME type) must be created
The Web Platform is modular: if you develop an application with a team, different team members can work on different aspects
Technologies are modular: there are optional parts that you don't have to know, while still being able to make complete applications
Things that aren't specific to the Web are done the same way as outside the Web (e.g., same programming languages, same tools, same terminology

Usability for the end user

Usability for the end user is a difficult goal for the creators of technology, because it is ultimately the implementers and, in the case of Web Applications, the Web developers who are responsible for the usability. Even the most well-designed technology, if it is powerful enough, allows people to make horrible applications. Still, W3C can do something:

Proven UI models are built-in (see also "Common tasks need little code..." above)
Proven UI models are efficient to implement (because speed is an important factor in the user's experience)
The metaphors in the languages and APIs correspond to metaphors in the UI, or are easily mapped (because we want end users to become Web developers themselves: The Web is a read-write medium)
If a technology has defaults (i.e., everything the developer can omit or forget), they are such that they are most likely to be useful for the end user (e.g., by default data is visible rather than hidden, communications are encrypted rather than cleartext, interaction follows the platform's UI guidelines rather than a fixed style)
Data and applications are independent and there are standards for all kinds of data (i.e., when a particular Web Application doesn't work for a user, the user can go to the app store for his platform and usually find some other application that does)
All interaction can be automated: the user can let his computer (a "User Agent" or "Intelligent Agent") do the interaction on his behalf, without requiring full AI
Technology is stable (new features arrive all the time, but the way you did it ten years ago also still works)
Web Applications are well integrated with the desktop on which they run (same mouse gestures, same keyboard shortcuts, cut & paste works, same save-file dialog, same fonts and colors…)