View source for 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 [http://w3c.github.io/bp-i18n-specdev/ Internationalization Best Practices for Spec Developers] (and it's [http://www.w3.org/International/techniques/developing-specs-dynamic 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 [http://www.w3.org/TR/charmod/ 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 [http://www.w3.org/TR/charmod-norm/ 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 [http://www.w3.org/TR/ltli/ 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 [http://www.w3.org/TR/jlreq/ Japanese], and are now working on [http://www.w3.org/TR/klreq/ Korean], [http://w3c.github.io/clreq/ Chinese], and [http://www.w3.org/TR/ilreq/ 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 [http://w3c.github.io/typography/ 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 [http://www.w3.org/International/tests/ 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===
See also the i18n WG [https://www.w3.org/International/wiki/Project_radar project radar].

'''Reviews, discussion & advice'''
* ongoing work, driven by Working Group activity

'''Developer guidelines'''
* Encoding spec
* Character Model for the World Wide Web: String Matching & Comparison (charmod norm)
* needs and issues surrounding locale formats on the Web, including Language Tags and Locale Identifiers for the World Wide Web

'''Requirements'''
* Chinese layout requirements, including Simplified & Traditional Chinese, Mongolian, Tibetan, and possibly Uighur
* Indic layout requirements
* Korean layout requirements
* Ethiopic and Arabic/Persian layout requirements projects in preparation

'''Gap analysis & bridging'''
* ruby markup in HTML5 and ruby styling in CSS
* bidi markup in HTML5
* Mongolian variant forms
* vertical text support for CJK and Mongolian
* support for CSS queries about typographic and layout requirements

'''Tests'''
* Encoding specification
* CSS & HTML tests, esp. to evaluate new i18n features being developed

'''Education & outreach'''
* Custom Counter Styles for International Content
* new article development, eg. use of new bidi features, new ruby features, vertical text features, etc
* ongoing maintenance and updating of existing resources, particularly in light of changes to HTML and CSS
* translations, conference presentations, MultilingualWeb workshops

'''Tracking collateral developments'''
* Unicode developments
* font and keyboard developments
* language technology and localization
* universal access and URLs

===Useful tracking documents===
* [https://www.w3.org/International/wiki/Project_radar Internationalization Working Group Project RADAR]
* [https://www.w3.org/International/wiki/Review_radar Internationalization Review Radar]
* [https://www.w3.org/International/wiki/Core_Pipeline Guidelines, Education & Outreach parking lot]
* [http://w3c.github.io/typography/ Improving text layout and typography on the Web and in eBooks]
* [http://www.w3.org/International/track/products Review tracker]
* [http://www.w3.org/International/technique-index Techniques indexes]

== 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]: [http://www.w3.org/People/Bos/DesignGuide/introduction.html 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…)