openui / openui/open-ui

Progressive enhancement of new html elements

Open
#198 25 comments 12 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

needs-triage
Dominant language
MDX
Stars
4.5k
Forks
226
Avg merge
2d 22h
Merged PRs (30d)
4

Description

TL;DR
I propose that we make progressive enhancement a goal for components in open UI and track questions we have around PE in this bug.

NB: no need to bikeshed the HTML structures below, they aren't well thought out, they exist just to enable a more concrete discussion.

Use lists to do progressive enhancement and have shiny new components

It is important for adoption that these components follow a strategy of progressive enhancement. I believe in some ways we can rely on the browsers built-in parsing behavior to make that happen. For example most browsers (afaik) would correct the following HTML by inserting a UL around it:

<!-- browser inserts a UL -->
<li>item 1</li>
<li>item 1</li>
<li>item 1</li>
<!-- browser closes the UL -->

We can use that behavior to our advantage to achieve progressive enhancement. For example this carousel would be navigable in older browsers because they would treat it like a list:

<carousel>
  <li>item 1</li>
  <li>item 1</li>
  <li>item 1</li>
</carousel>

More components than you would expect turn out to have lists as an underlying structure. This can allow us to create declarative HTML that pushes the web forward, while still supporting older browsers.

Can we identify some of the most important progressive enhancement challenges in this bug?

Q: how can we ensure that headings are navigable in new elements?
<tabs>
  <tabslist>
    <li>tab 1</li> <!-- not selected tabs are essentially navigation to non-visible content -->
    <li>tab 2</li>
    <li selected>Tab 3</li> <!-- the currently selected tab functions as a heading for the visible content. How do we retain it's headingness for assistive tech? -->
  </tabslist>
  <content>
  </content>
</tabs>
Q: How do we ensure clickable elements are links for older browsers? e.g. in the tabs example, the li are links to the content below. Would this need a polyfill? Do we need a way of saying treat this li like an a?

Leonie and Brian quite likely have more to add here as they brought this issue to my attention. What other assistive tech issues need to be addressed?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by reviewing the carousel and tabs examples, then determine which progressive-enhancement and assistive-technology questions are in scope. Done is a concrete, agreed scope for addressing the listed questions.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
accessibility, frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.