@gjsify/react-native 0.47.0 → 0.48.0

package/PROPS.md

@@ -11,8 +11,13 @@ The **answer** column is `acceptsProp()`'s: `property`, `event`, `style`, `file`
 `refused` throws a `PrimitiveError` at render time. A prop that appears in no row throws too,
 naming the ones that are here.
 
-Ask this from a test rather than reading it: `acceptsProp("Text", "onPress")` is `false` and
-`explainProp("Text", "onPress")` is the sentence a render would have thrown (ADR 0039).
+A prop can be answered and still refuse some of its VALUES by name — `accessibilityRole` is
+the one that does. Those rows name the refused values and the sentences follow the table.
+
+Ask this from a test rather than reading it: `acceptsProp("Text", "onPress")` is `false`,
+`explainProp("Text", "onPress")` is the sentence a render would have thrown, and
+`explainPropValue("View", "accessibilityRole", "keyboardkey")` is the one it would have thrown
+for that value (ADR 0039).
 
 ## `<View>`
 
@@ -20,30 +25,40 @@ widget `GtkBox` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `nativeID` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `onLayout` | refused | — | GTK reports its allocation through `Gtk.Widget.vfunc_size_allocate`, a SUBCLASS override rather than a signal, so there is no handler to bind. `useWindowDimensions` (tier P2) is the window-level answer |
 | `pointerEvents` | property | `can-target` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Text>`
 
 widget `GtkLabel` · a text child writes `label`.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | announcement | `notify::label`, `Gtk.Accessible.announce()` | — |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `adjustsFontSizeToFit` | refused | — | GTK has no shrink-to-fit text; a label ellipsizes or wraps. Use `numberOfLines` with `ellipsizeMode` |
 | `allowFontScaling` | ignored | — | text scaling is a desktop-wide GNOME setting, not a per-label opt-in |
 | `ellipsizeMode` | property | `ellipsize` | — |
@@ -56,18 +71,28 @@ widget `GtkLabel` · a text child writes `label`.
 | `selectable` | property | `selectable` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Pressable>`
 
 widget `GtkButton` · a text child writes `label`.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `android_ripple` | ignored | — | an Android-only ripple; Adwaita has its own press feedback |
 | `delayLongPress` | refused | — | see `onLongPress` |
 | `disabled` | property | `sensitive` | — |
@@ -82,18 +107,28 @@ widget `GtkButton` · a text child writes `label`.
 | `pointerEvents` | property | `can-target` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<ScrollView>`
 
 widget `GtkScrolledWindow` · children go into `GtkBox` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `contentContainerClassName` | ignored | — | read directly as the content node’s class list |
 | `contentContainerStyle` | ignored | — | read directly as the content node’s style set |
 | `horizontal` | property | `orientation`, `hscrollbar-policy`, `vscrollbar-policy` | — |
@@ -110,18 +145,28 @@ widget `GtkScrolledWindow` · children go into `GtkBox` · takes no text child.
 | `showsVerticalScrollIndicator` | property | `vscrollbar-policy` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<ActivityIndicator>`
 
 widget `AdwSpinner` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `animating` | property | `visible` | — |
 | `color` | style | `style: color` | — |
 | `hidesWhenStopped` | ignored | — | a stopped `Adw.Spinner` is a hidden one here — there is no property that stops it while it is on screen (measured), so this is already the behaviour |
@@ -131,18 +176,28 @@ widget `AdwSpinner` · takes no text child.
 | `size` | property | `width-request`, `height-request` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<TextInput>`
 
 widget `GtkEntry` · a text child writes `text` · a `ref` receives the `text-input` handle, not the widget.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `autoCapitalize` | ignored | — | an on-screen keyboard behaviour; a hardware keyboard has no shift state to preset |
 | `autoComplete` | ignored | — | is Android’s autofill hint, and there is no autofill service on a GTK desktop to hint to — a password manager fills a field through the accessibility bus or a paste, neither of which the widget declares anything for. `keyboardType` is the one hint that does land: it writes `Gtk.Entry:input-purpose`, which an input method reads |
 | `autoCorrect` | ignored | — | an on-screen keyboard behaviour |
@@ -168,6 +223,16 @@ widget `GtkEntry` · a text child writes `text` · a `ref` receives the `text-in
 | `textContentType` | ignored | — | is `autoComplete`’s iOS spelling and has the same absent addressee. Note `Gtk.Accessible` does carry an `autocomplete` PROPERTY, and it is a different thing: it describes a widget that completes its own text (a combo box), not a system that fills it in |
 | `value` | property | `text` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<TextInput multiline>`
 
 widget `GtkTextView` · takes no text child · a `ref` receives the `text-input` handle, not the widget.
@@ -176,12 +241,12 @@ One React Native prop, two GTK widgets: `multiline` selects this row instead of
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `autoCapitalize` | ignored | — | an on-screen keyboard behaviour; a hardware keyboard has no shift state to preset |
 | `autoComplete` | ignored | — | is Android’s autofill hint, and there is no autofill service on a GTK desktop to hint to — a password manager fills a field through the accessibility bus or a paste, neither of which the widget declares anything for. `keyboardType` is the one hint that does land: it writes `Gtk.Entry:input-purpose`, which an input method reads |
 | `autoCorrect` | ignored | — | an on-screen keyboard behaviour |
@@ -207,18 +272,28 @@ One React Native prop, two GTK widgets: `multiline` selects this row instead of
 | `textContentType` | ignored | — | is `autoComplete`’s iOS spelling and has the same absent addressee. Note `Gtk.Accessible` does carry an `autocomplete` PROPERTY, and it is a different thing: it describes a widget that completes its own text (a combo box), not a system that fills it in |
 | `value` | refused | — | `Gtk.TextView` keeps its content in a `Gtk.TextBuffer` rather than in a property (measured: 61 properties, no `text`), so there is nothing for this layer to set as data. Drop `multiline` for a `Gtk.Entry`, or reach the buffer through a ref |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Switch>`
 
 widget `GtkSwitch` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `disabled` | property | `sensitive` | — |
 | `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `ios_backgroundColor` | ignored | — | an iOS-only fallback colour |
@@ -230,18 +305,28 @@ widget `GtkSwitch` · takes no text child.
 | `trackColor` | refused | — | Adwaita paints the switch from the theme’s accent colour, and its track is a CSS `slider`/`trough` subnode rather than a property. Style it from the application stylesheet |
 | `value` | property | `active` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Image>`
 
 widget `GtkPicture` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `alt` | property | `alternative-text` | — |
 | `blurRadius` | refused | — | is a per-pixel effect. GTK composites a `Gdk.Paintable` and has no filter property on the widget that draws it — the counterpart is a `Gsk` render node or a `Gtk.Snapshot` subclass, which is a widget of its own rather than a prop on this one |
 | `capInsets` | refused | — | is iOS nine-part stretching. GTK’s counterpart is a CSS `border-image` on a widget’s background, which is a different widget and a different property set |
@@ -264,18 +349,28 @@ widget `GtkPicture` · takes no text child.
 | `testID` | property | `name` | — |
 | `tintColor` | refused | — | is a per-pixel effect. GTK composites a `Gdk.Paintable` and has no filter property on the widget that draws it — the counterpart is a `Gsk` render node or a `Gtk.Snapshot` subclass, which is a widget of its own rather than a prop on this one |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<ImageBackground>`
 
 widget `GtkOverlay` · children go into `GtkBox` · backdrop `GtkPicture` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `alt` | property | `alternative-text` | — |
 | `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `imageRef` | refused | — | hands back the inner `Image`’s instance. This element’s `ref` is the `Gtk.Overlay`; the picture is its main child and `overlay.get_child()` reaches it, so a second ref would be a second way to say the same thing |
@@ -287,18 +382,28 @@ widget `GtkOverlay` · children go into `GtkBox` · backdrop `GtkPicture` · tak
 | `source` | file | `file` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<TouchableOpacity>`
 
 widget `GtkButton` · a text child writes `label`.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `activeOpacity` | refused | — | sets the pressed appearance, which on GTK is the CSS `:active` pseudo-class rather than a prop (ADR 0032 § 7). Write `active:opacity-70` — it resolves through the same variant mechanism as every other utility, reads the project's own token scale, and GTK animates it with no re-render at all |
 | `delayLongPress` | refused | — | see `onLongPress` |
 | `delayPressIn` | refused | — | see `onPressIn` — there is no press-in event to delay |
@@ -317,18 +422,28 @@ widget `GtkButton` · a text child writes `label`.
 | `testID` | property | `name` | — |
 | `touchSoundDisabled` | ignored | — | an Android touch sound; a desktop button makes none |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<TouchableHighlight>`
 
 widget `GtkButton` · a text child writes `label`.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `activeOpacity` | refused | — | sets the pressed appearance, which on GTK is the CSS `:active` pseudo-class rather than a prop (ADR 0032 § 7). Write `active:opacity-70` — it resolves through the same variant mechanism as every other utility, reads the project's own token scale, and GTK animates it with no re-render at all |
 | `delayLongPress` | refused | — | see `onLongPress` |
 | `delayPressIn` | refused | — | see `onPressIn` — there is no press-in event to delay |
@@ -350,18 +465,28 @@ widget `GtkButton` · a text child writes `label`.
 | `touchSoundDisabled` | ignored | — | an Android touch sound; a desktop button makes none |
 | `underlayColor` | refused | — | sets the pressed appearance, which on GTK is the CSS `:active` pseudo-class rather than a prop (ADR 0032 § 7). Write `active:bg-<token>` — it resolves through the same variant mechanism as every other utility, reads the project's own token scale, and GTK animates it with no re-render at all |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<TouchableWithoutFeedback>`
 
 widget `GtkBox` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `delayLongPress` | refused | — | see `onLongPress` |
 | `delayPressIn` | refused | — | see `onPressIn` — there is no press-in event to delay |
 | `delayPressOut` | refused | — | see `onPressIn` |
@@ -379,18 +504,28 @@ widget `GtkBox` · takes no text child.
 | `testID` | property | `name` | — |
 | `touchSoundDisabled` | ignored | — | an Android touch sound; a desktop button makes none |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Button>`
 
 widget `GtkButton` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `color` | refused | — | is the button’s background on Android and its text colour on iOS — one prop, two meanings, and GTK has a third answer: `suggested-action` and `destructive-action` are Adwaita’s own classes for the two cases a colour is usually asking for. Set them from the application stylesheet, or use `<Pressable>` |
 | `disabled` | property | `sensitive` | — |
 | `hasTVPreferredFocus` | ignored | — | an Android TV focus hint |
@@ -407,36 +542,98 @@ widget `GtkButton` · takes no text child.
 | `title` | property | `label` | — |
 | `touchSoundDisabled` | ignored | — | an Android touch sound; a desktop button makes none |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<SafeAreaView>`
 
 widget `GtkBox` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `nativeID` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `onLayout` | refused | — | GTK reports its allocation through `Gtk.Widget.vfunc_size_allocate`, a SUBCLASS override rather than a signal, so there is no handler to bind. `useWindowDimensions` (tier P2) is the window-level answer |
 | `pointerEvents` | property | `can-target` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
+## `<Modal>`
+
+widget `AdwDialog` · children go into `GtkBox` · takes no text child.
+
+| prop | answer | GTK | why |
+|---|---|---|---|
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
+| `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
+| `allowSwipeDismissal` | refused | — | swipe-to-dismiss is a touch gesture; the desktop dismissal is Escape or a click on the backdrop, and `onRequestClose` already reports both |
+| `animationType` | refused | — | libadwaita animates the presentation itself and picks the animation from `Adw.Dialog:presentation-mode` — a floating sheet fades and scales, a bottom sheet slides up — so there is no property that selects one. Reach the dialog through a `ref` and set `presentation-mode` if the sheet should arrive from the bottom |
+| `backdropColor` | refused | — | see `transparent` — the dim layer is libadwaita’s and is painted from the theme |
+| `hardwareAccelerated` | ignored | — | an Android window flag; GTK4 renders through GSK either way |
+| `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
+| `modalRef` | refused | — | React Native’s second ref, to the native modal host view. There is one node here and `ref` already hands back its `Gtk.Widget`; two refs to one widget would be two names for the same thing |
+| `nativeID` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
+| `navigationBarTranslucent` | ignored | — | see `statusBarTranslucent` |
+| `onDismiss` | refused | — | would never fire. The only thing that dismisses a dialog here is the element being unrendered, and the host disconnects a node’s handlers BEFORE it retracts the node — so `Adw.Dialog::closed` is emitted with the handler already gone. A callback that fires for no dismissal at all is worse than one that says so. Do the work in the effect cleanup of whatever renders the `<Modal>` |
+| `onLayout` | refused | — | GTK reports its allocation through `Gtk.Widget.vfunc_size_allocate`, a SUBCLASS override rather than a signal, so there is no handler to bind. `useWindowDimensions` (tier P2) is the window-level answer |
+| `onOrientationChange` | refused | — | see `supportedOrientations` — nothing rotates |
+| `onRequestClose` | event | `close-attempt` | — |
+| `onShow` | event | `map` | — |
+| `presentationStyle` | refused | — | iOS presentation vocabulary. The GTK axis is `Adw.Dialog:presentation-mode` (auto / floating / bottom-sheet), which says WHERE the sheet sits rather than how much it covers, so no member of this maps onto one. Set that property through a `ref` |
+| `statusBarTranslucent` | ignored | — | a desktop window has no status bar to go under |
+| `supportedOrientations` | refused | — | a desktop window has no orientation to lock |
+| `testID` | property | `name` | — |
+| `transparent` | refused | — | an `Adw.Dialog` is always a sheet over libadwaita’s own dimmed backdrop; there is no full-bleed transparent mode, and faking one would be a sheet with no chrome that still dims. For an overlay you paint yourself, put an absolutely positioned `<View>` in a `<View>` — that becomes a `Gtk.Overlay` — instead of a `<Modal>` |
+| `visible` | ignored | — | read directly by the binding: the element is rendered only while it is true |
+
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<Icon>`
 
 widget `GtkImage` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `color` | style | `style: color` | — |
 | `id` | refused | — | would write `Gtk.Widget:name`, and so does `testID`. Two props for one property is the silent-drop shape the host refuses by name (`signalTaken`), so this layer picks one: use `testID` |
 | `name` | property | `icon-name` | — |
@@ -445,18 +642,28 @@ widget `GtkImage` · takes no text child.
 | `size` | property | `pixel-size` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<KeyboardAvoidingView>`
 
 widget `GtkBox` · takes no text child.
 
 | prop | answer | GTK | why |
 |---|---|---|---|
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `behavior` | ignored | — | describes how to move out of an on-screen keyboard’s way, and none appears |
 | `contentContainerStyle` | refused | — | styles the inner view React Native adds to do the avoiding, and there is no avoiding here — so there is no second node to style. Put it on `style`, which lands on the one box this element is |
 | `enabled` | ignored | — | see `behavior` — the avoidance is already off |
@@ -467,6 +674,16 @@ widget `GtkBox` · takes no text child.
 | `pointerEvents` | property | `can-target` | — |
 | `testID` | property | `name` | — |
 
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here
+
 ## `<FlatList>`
 
 widget `GtkBox` · children go into `GtkScrolledWindow` · takes no text child.
@@ -477,12 +694,12 @@ widget `GtkBox` · children go into `GtkScrolledWindow` · takes no text child.
 | `ListEmptyComponent` | ignored | — | rendered by the component instead of the scroller |
 | `ListFooterComponent` | ignored | — | rendered by the component, after the scroller |
 | `ListHeaderComponent` | ignored | — | rendered by the component, before the scroller |
-| `accessibilityHint` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityLabel` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityHint` | accessible | `Gtk.Accessible.update_property(): help-text` | — |
+| `accessibilityLabel` | accessible | `Gtk.Accessible.update_property(): label` | — |
 | `accessibilityLiveRegion` | refused | — | declares that a screen reader should speak this element when its CONTENT changes. GTK has the announcement — `Gtk.Accessible.announce(message, priority)` since 4.14 — but not the watch: it is an imperative call, and this element’s content is a SUBTREE, which GTK emits no signal for. `<Text>` answers this prop, because its content is one property (`Gtk.Label:label`) and so is both the moment and the message. Elsewhere, call `announce()` on the widget through a ref when you change the content |
-| `accessibilityRole` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessibilityState` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
-| `accessible` | refused | — | GTK carries accessibility through `Gtk.Accessible.update_property()`, an imperative call, not through a widget property — so there is nothing for this layer to set as data. `AccessibilityInfo` (tier P3) is the entry that owns this, and GTK’s model maps onto the props well once it exists |
+| `accessibilityRole` | property | `accessible-role` | refuses `drawerlayout`, `horizontalscrollview`, `keyboardkey`, `pager`, `scrollview`, `slidingdrawer`, `summary` — see below |
+| `accessibilityState` | accessible | `busy → Gtk.Accessible.update_state(): busy`, `checked → Gtk.Accessible.update_state(): checked`, `disabled → Gtk.Accessible.update_state(): disabled`, `expanded → Gtk.Accessible.update_state(): expanded`, `selected → Gtk.Accessible.update_state(): selected` | — |
+| `accessible` | ignored | — | asks for two things, and GTK already answers one: every GTK widget is in the accessibility tree, so “this element is an accessibility element” is the desktop default rather than an opt-in. The other thing it asks — merge my whole subtree into ONE accessible node, which is what `accessible={true}` does on iOS — GTK has no mechanism for, and a desktop screen reader navigates the widget tree it is given. To take an element OUT of that tree, set `accessibilityRole="none"`: it is the one prop that writes `Gtk.Accessible:accessible-role`, and two props writing one property is the silent-drop shape this table refuses by name |
 | `columnWrapperStyle` | refused | — | see `numColumns` |
 | `contentContainerStyle` | refused | — | styles the box React Native puts the rows in, and there is no such box: `Gtk.ListView` builds each row from the factory and owns the space between them. Style the row inside `renderItem`, or the list itself through `style` |
 | `data` | ignored | — | read by the component, which drives the Gio.ListStore from it |
@@ -523,3 +740,13 @@ widget `GtkBox` · children go into `GtkScrolledWindow` · takes no text child.
 | `viewabilityConfig` | refused | — | see `onViewableItemsChanged` |
 | `viewabilityConfigCallbackPairs` | refused | — | see `onViewableItemsChanged` |
 | `windowSize` | refused | — | tunes React Native’s own virtualisation, and `Gtk.ListView` does that job itself — it creates and recycles rows through the factory as the viewport moves (measured: 205 of 500 rows set up in a 400×300 window) and installs no property that changes the batching. There is nothing for this to set |
+
+`accessibilityRole` is answered for every other value, and these are refused by name:
+
+- `drawerlayout` — names Android’s DrawerLayout. The desktop pattern survives the component (`Adw.OverlaySplitView`), but it is a widget rather than a role — drop the prop and give the drawer an `accessibilityLabel`; React Native’s role list has no `navigation`, and the widget carries the rest
+- `horizontalscrollview` — names an Android class, like `scrollview` — use `<ScrollView horizontal>` and drop the prop
+- `keyboardkey` — describes a key of an on-screen keyboard, and neither GTK nor ARIA has a role for one — a desktop keyboard is the input method, not a widget in your tree. If you are building a keypad, the keys are `accessibilityRole="button"`; the container needs no role, because React Native has no spelling for ARIA’s `group` and a plain `<View>` is already the `generic` a screen reader walks through
+- `pager` — names Android’s ViewPager. GTK’s counterpart is a `Gtk.Stack`, and the role a screen reader wants on it is `tablist` when it has visible switchers and nothing at all when it does not
+- `scrollview` — names Android’s ScrollView class rather than a role, and this layer already answers the idea: `<ScrollView>` becomes a `Gtk.ScrolledWindow`, whose accessibility a screen reader reads from the widget itself. Drop the prop
+- `slidingdrawer` — names a deprecated Android class — see `drawerlayout`
+- `summary` — is an iOS trait for the one element VoiceOver reads first when an app launches, and GTK has no counterpart because a desktop screen reader announces the focused widget instead. Put the text in the window title, or carry it as `accessibilityLabel` on the element it summarises — React Native’s role list has no `status`, so there is no role to give it here