chore: add flipper spec

[chrisdholt]

Description

This PR proposes adding a new spec for a flipper component.

Issue type checklist

• Chore: A change that does not impact distributed packages.
• Bug fix: A change that fixes an issue, link to the issue above.
• New feature: A change that adds functionality.

Is this a breaking change?

• This change causes current functionality to break.

Process & policy checklist

• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[chrisdholt]

Feedback is welcome on a better name here :). Per previous comments by @EisenbergEffect, something like hiddenFromAssistiveTechnologies is a bit verbose. As an FYI, this convention was used here as an initial stub because the same language is often used by the W3C spec to denote when something is not exposed to AT users.

[nicholasrice]

We could maybe do something like:

@attr({attribute: "aria-hidden"})
public hiddenFromAT: boolean = true;

Then then user could simply write <fast-flipper aria-hidden="false" /> to override. Note that this doesn't seem to actually work - aria-hidden is overridden by the default property value but I think that might be a bug. You might also need to do write a custom converter.

[EisenbergEffect]

Hmm. Overwriting built-ins may not be something we can support. I'm not sure. It would be nice to use aria-hidden if we can. Do we need to do anything in our own code in response to this changing?

[nicholasrice]

I think it just needs to be hidden by default - perhaps when connected we could just check to see if the attribute exists, and if not set it imperatively.

[EisenbergEffect]

That's an interesting idea. What do you think @chrisdholt ?

[chrisdholt]

So, if aria-hidden exists on the host, use that value and respond accordingly. If it doesn't exist, set aria-hidden in connectedCallback?

[chrisdholt]

@nicholasrice @EisenbergEffect just want to confirm I'm understanding the proposed implementation (above)

[chrisdholt]

Confirmed offline, I like this idea and think we should pursue it in implementation. 👍

[EisenbergEffect]

I think we can move ahead with this. We may just need to do some experimentation around the aria-hidden scenario. Ideally, I think we want to just enable aria-hidden to work, but to provide a default value for that. The trick is that we don't want to overwrite the built-in, but we do want to get change callbacks. I'm not sure if the platform is going to let us do that. I can play with some things. If we can't make that work, we can always fallback to the original proposal of using hiddenFromAT .

Also, we could set up a MutationObserver on the host and observe attributes, but that seems a bit overkill if we can avoid it.

[EisenbergEffect]

Hmm. Overwriting built-ins may not be something we can support. I'm not sure. It would be nice to use aria-hidden if we can. Do we need to do anything in our own code in response to this changing?

[EisenbergEffect]

Can we just let the end user decide by adding aria-hidden themself or is there something we need to do internally in response to the hiddenFromAT property changing?

[chrisdholt]

Some of this depends on how we want to default it. If you default it to being exposed to assistive tech, then you need to drop the tabindex and add aria hidden in the event you want to hide it. If you default to hidden from assistive tech, the end user needs to add tabindex, override the internal aria-hidden behavior, and add the role of button. It's shown as persisting above, but I don't think we would add that if it were not exposed to AT. So, in a sense it's a swing of 3 properties on the implementors side to successfully transition between these states. I see a single prop to toggle this as a value add for empowering accessibility; however, we'd technically be empowering it as well by making someone handle it themselves.