docs: semantics docs#635
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
| ] | ||
| }, | ||
| { | ||
| "group": "Accessibility & Interaction", |
There was a problem hiding this comment.
I recall us chatting about this, but I don't remember why we landed on & Interaction?
I'd prefer just Accessibility.
There was a problem hiding this comment.
I think it was to better encompass focus, but I think "Accessibility" is good enough. :thu
|
|
||
| At a high level, semantics are made up of: | ||
|
|
||
| - [Type](#semantic-type) — what the element is (for example, button, image, or heading) |
|
|
||
| Semantics describe what an element is and how it should be understood. Adding semantics makes your experiences accessible, allowing screen readers to correctly describe and navigate your content. | ||
|
|
||
| At a high level, semantics are made up of: |
There was a problem hiding this comment.
We should also include Semantic Actions somewhere.
|
|
||
| Semantics describe what an element is and how it should be understood. Adding semantics makes your experiences accessible, allowing screen readers to correctly describe and navigate your content. | ||
|
|
||
| At a high level, semantics are made up of: |
There was a problem hiding this comment.
I like this description for Roles, Traits, and States:
Architecture: Role / Trait / State
- Role - what the node is (button, checkbox, tab, etc.)
- Trait - what the node can do (expandable, selectable, checkable, etc.)
- State - what the node is doing (expanded, selected, checked, etc.)
Some state flags are only meaningful when their corresponding trait is set. Without the trait, the platform sees the property as not applicable.
| - [Type](#semantic-type) — what the element is (for example, button, image, or heading) | ||
| - [Properties](#semantic-properties) — additional information like label, value, or hint | ||
| - [Traits](#traits) — capabilities an element has (for example, selectable or expandable) | ||
| - [State](#state) — the current value of a trait (for example, selected or disabled) |
There was a problem hiding this comment.
Not all states relate to a trait. It's just that some states are gated by a trait
There was a problem hiding this comment.
Never mind. Your other comment explains it " Some state flags are only meaningful when their corresponding trait is set. Without the trait, the platform sees the property as not applicable."
|
|
||
| ## Adding Semantics | ||
|
|
||
| <img src="/images/accessibility-interaction/semantics/adding-semantics.gif" width="300" /> |
There was a problem hiding this comment.
Might not be immediately clear where to find this, as the video doesn't show it's the inspector
There was a problem hiding this comment.
Updated.
btw There are other gifs to add, but the ui is still WiP.
| <Step title="Add Semantics"> | ||
| Select an element in your scene. In the right sidebar, click the `+` button in the **Semantics** panel to enable semantics for that element. | ||
| </Step> | ||
| <Step title="Choose a Type"> |
| For example, a slider that controls volume might have the label: | ||
| `Volume` | ||
|
|
||
| <Info> |
There was a problem hiding this comment.
Let's remove this. This is true, but not all platforms and screen readers are equal. For example, the web might announce "expanded", but iOS does not. There might be times when authors want to provide a more unique experience by controlling the label instead of relying on the role.
| Avoid including the type in the label (for example, "slider" or "button"). Screen readers already announce the element’s type. | ||
| </Info> | ||
|
|
||
| <Info> |
There was a problem hiding this comment.
Let's add a new section called "Semantic Inference".
Here we can detail that certain Rive components will infer it's label (and other properties) automatically. At this time it's only a Text component that will automatically set its label to the text set.
There was a problem hiding this comment.
I'm gonna push back a little. :)
Inference isn't a sibling section to traits and properties, it's a child of both. It's also not something you need to learn about - it feels like something most people will figure out on their own.
The only time people might look for it in the docs is if they've added a text field and can't figure out why they can't change the role. In that case, they'll go to the "Role" section, not the "semantic inference" section.
| Some elements, like text inputs, automatically infer their semantic type. | ||
| </Info> | ||
|
|
||
| ## Semantic Properties |
There was a problem hiding this comment.
Might be nice to state the type these properties should be. At this stage it's all strings, but maybe in the future we others.
|
|
||
| For example, an element with the **selectable** trait will have a **selected** state. | ||
|
|
||
| Use data binding to keep semantic states in sync with your Rive file. For example, bind a boolean from your view model to the **toggled** state of a switch. |
There was a problem hiding this comment.
You can also key the state on an animation timeline
|
|
||
| Small issues—like a missing label or incorrect state—can make elements confusing or unusable for screen reader users. | ||
|
|
||
| ### How to Test |
There was a problem hiding this comment.
Maybe worth calling out that this should be tested at runtime, and not the editor. Or maybe soon we can say the mirror apps
| description: "" | ||
| --- | ||
|
|
||
| Semantics describe what an element is and how it should be understood. Adding semantics makes your experiences accessible, allowing screen readers to correctly describe and navigate your content. |
There was a problem hiding this comment.
At some point early in the document, we should highlight that this is in Early Access, and that runtime support is currently in development or released as experimental.
Inconsistencies should be reported to us, but it's worth noting that not all Roles we expose are valid across every runtime. We will document these over time.
We also need a runtime page to detail how to enable (opt-in at this stage), plus how to test etc. But that can be a separate PR.
Then we also need to update the feature support page to list out the state of this feature support on runtimes. Currently we can say that Flutter has experimental support from version 0.14.6
tylernij
left a comment
There was a problem hiding this comment.
Gordon has some suggestions but afterwards 👍
|
Thanks @HayesGordon and @tyler. I've implemented most of your feedback, though there are a couple of todo's I'll add to the description. |
|
|
||
| #### Adding ARIA Label | ||
|
|
||
| At a minimum - if it is important to convey the text value displayed in the Rive animation to all users, add an `aria-label` to the `<canvas>` element with the text value from the animation. Screen readers may read this label out immediately as it parses out the DOM contents. You'll also want to add `role="img"` to the `<canvas>` element as well. |
There was a problem hiding this comment.
nit: this small aria label section could still be useful as a "at a minimum, if semantic nodes are not used in your Rive graphic"

Remaining todo's: