604c752

dfa10d9

0976d4a

6d33c55

A little back story: #25

Motivation: increase developer productivity thus increase library utility by providing cross-platform components.

However, do native platforms have accessibility requirements? What are those? How can those be achieved? What are some good resources for successful accessible native components?

Laying out the groundwork should build some momentum.

Looks like we're missing a license on this repository. Whooooops.

MIT? I think that's the most friendly to open source projects.

The sooner the better?

I just enrolled into the Sponsorship beta program.

I would like to make react-aria-components the main project.

• Set up (an approved) sponsorship profile
• Enable sponsor button in project
• Add (accessible) sponsor link in demo pages

Storybook 5 has been released, and it looks really good! What do you think @juanca about using it for the examples in this repo?

Should we use it, we'll get:

• Sexy looking site/examples
• Real easy to add examples
• Built-in accessibility for the site/examples!

Downsides are:

• Less control

In any case, I'm going to look at implementing a demo of this to look at

From w3c/aria-practices#323 (comment)

This was added to account for cases where a tab panel may not include any focusable interactive elements, or if a large amount of textual content appears at the beginning of the tabpanel and the first focusable active element is at the end, such as a license agreement form where the Agree button is at the very end.
If the tabpanel is not focusable, then sighted keyboard-only users will not be able to tab to the tabpanel content and read it from the beginning on down, but will instead jump to Agree and entirely skip all of the main content. This is also helpful for screen reader users who may wish to move directly from the focused expanded Tab and be placed at the beginning of the newly rendered Tabpanel content, instead of jumping passed it or moved to the end of it unexpectedly.

As I learn more about the different usages of the Grid role, a clear distinction between its usages seems to grow larger.

There seems to be two different usages of a grid:

• Data grid: which is the current implementation in this package
• Layout grid: which is more abstract and is not tabular

I think it will be beneficial to define these two as separate components -- and compose from each other.

More research needs to be done but using this to track the idea.

b284b1d

Looks like there was a hiccup with the linting PR:

npm ERR! peer dep missing: eslint@^4.19.1, required by [email protected]
npm ERR! peer dep missing: eslint@>=1.6.0 <5.0.0, required by [email protected]
npm ERR! peer dep missing: eslint@^4.19.1, required by [email protected]

Everything seems functional but there are cases when the linting is just whack.

639e610

I think it may be worthwhile to release components individually (as well as a whole set together).

Initially, this repository was intended to only support the grid and tree-grid components. And I just recently got access to react-treegrid package name. https://www.npmjs.com/package/react-treegrid

Ideally, we have a straightforward process for releases all these packages.

For example, perhaps have a package.json for react-tree-grid (once I can rename the package) and a script to package the appropriate files -- minimal footprint.

There are prop-type validation errors when rendering the grid example.

The GridRow and GridCell have require properties which are provided after rendering via React.cloneElement.

In order to fix this, possible solutions are:

• Use context to provide dynamic values from Grid to GridRow and GridCell
• Refactor API to always use render props everywhere
• Dig for other solutions

Regardless of the solution, performance should be evaluated! As far as I remember, Cursor was pretty fast as well as the grid example.

720c84b

Although VoiceOver has good keyboard navigation in the grid example, it is still non-compliant with keyboard navigation outside VoiceOver.

This is an example with basic cells and keyboard navigation.

Babel warns when corejs is missing from the configuration.

This is opinion, but, even though we've configured the whole per branch pages stuff, there's no reason not to make those really attractive to increase interest from the public. It's been pretty proven over time that open source projects with attractive pages gain traction.