Open A11YOpen A11Y GitHub

Most recent revision: April 1, 2020

Vision

The web deserves interoperability between component frameworks and design systems. The UI community is in a similar place as the industrial revolution prior to standardization. Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps.

This should not be the case. The UI community should standardize namings and structures for common components. We should also standardize a way of theming these components. We should set a path for existing solutions to converge and for browsers to natively provide these things in the future.

UI component patterns have evolved and stabilized but have not made their way to to browsers or standards. Designers and developers reinvent the same components for every product they build. When building a web app or web page designers and developers should have a common set of components at their disposal. We shouldn't have to rebuild a dropdown, modal dialog, split button, or other components before we build our products.

Goals

These are the goals Open UI believes will realize the above vision.

  • Document component names as they exist today
  • A common language for describing UIs and design systems
  • Browser standards for web app components

Scope of work

  • Utilize descriptivism of common patterns to identify and standardize on:
    • Component names and parts
    • States
    • Behaviors
    • How behaviors transition state (eg: keyboard or pointer interaction)
  • The necessary accessibilty requirements (this is not in place of WIA-ARIA or WICAG but linking where appropriate to alleviate implementor pain)
  • Upon discovery of gaps in the web platform, denote those and raise relevant issues to standards bodies
  • Design system terminology

Out of scope

  • Standardization of appearance of the component

Process for creation of a pull request

The below process aims for efficiency and asynchronous changes but also allows for transparency and opportunities to ensure consesus from the community.

  • Research should be done across the industry for each aspect of the component
  • Based on investigation, curate decisions and propose an Open UI resolution
  • Open a PR regarding your proposal
  • Two members of the community group need to review and sign off on the change\
  • Merge of the review sign off will be done by the editors of Open UI. Current editors are in the codeowners file.
  • Add label of needs merge for review by the community group and editors

Process for consensus on issues

Consensus on individual issues does not equate to the specification's current stage

In order to ensure transparency and that we have consensus from the community the following needs to occur for each contribution:

  • Upon merge or can't agree on solution to accomplish the requirements for merging a PR.

  • Add the label agenda+ and be prepared to speak to it on the upcoming telecon where your agenda item is discussed

    • Note: even if it was successfuly merged, it will still be raised on the call to draw attention to it in order to ensure if people disagree they can raise their concerns.

  • If there is a disagreement a resolution will try to be gained on the telecon. In order to gain consensus it is the majority opinion of those on the call.

    Note: Resolutions can be over-turned upon new information becoming available Note: It is helpful for efficiency to have denoted in the PR or issue the proposed options so that you can quickly cover the options and the group can discuss it and vote on it.

Becoming an editor

Being an editor of a specification is an important responsibility. You need to ensure that the specifications you're responsible for continue to make progress. Additionally you should be one of the reviewers of PRs to the specifications you are an editor of.

An editor must:

  • Be a member of the community group
  • Have five substantial technical contributions to a specification that they wish to edit
  • Be nominated for editorship by either the chairs or someone that is currently an editor of that specification
  • Resolved on by the community during telecon or two other editors or chairs

Role of the chairs

There is no additional weight to the chairs vote when making a decision that requires consensus. The chairs' primary responsibilities are:

  • Facilitate meetings
  • Ensure progress towards goals is made
  • Create and foster a respectful and productive atmosphere for the community
  • Make sure that processes outlined in the charter are followed by the members

Selection of Community Group Chairs

Upon the need or desire for adding/changing co-chairs the process will be as such.

  • Propose in an issue your chiar nomination
  • Set label to agenda+
  • The nominee should already be an editor
  • On the telecon there will be a formal vote for consensus