Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Case for revised data model: labelled_by

Abierto
  • ¿Algo no está bien?
#583 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
rust
Área
accessibility

Línea de trabajo

Comienza rastreando el modelo de datos de Node y la ruta de actualización parcial del árbol de sombra de accesibilidad, centrándote en cómo se asigna y conserva labelled_by cuando se reemplaza un Node. El issue presenta tres diseños posibles, pero no selecciona ninguno; para darlo por terminado sería necesario acordar un modelo de datos y definir el comportamiento para conservar o eliminar las relaciones labelled_by.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Context

If I understand correctly, the labelled_by property allows one Node to be labelled by another, for example a CheckBox with a separate Label widget, both wrapped under some CheckBoxWithLabel widget.

The CheckBox widget doesn't know about the Label (which is external), hence the labelled_by property can only be set by the parent widget (unless the parent explicitly asks the CheckBox to store the identifier of its label, but this is a restrictive and over-complex design).

Motivation: partial tree updates

In the case that a full accessibility tree must be generated the above is fine, but in the case that the CheckBox value changes and the widget tries to update its Node value in the accessibility shadow-tree, it's harder to do this without losing the labelled_by relationship.

Suggestions

I can see a couple of possible solutions here:

  1. Allow access to the prior state of nodes in the accessibility tree: then CheckBox can copy its old value and update it. (This change is quite significant and may be undesirable.)
  2. Move the labelled_by property out of Node to another data structure (e.g. Vec<(NodeId, NodeId)>). Logically a node cannot label more than one other node; this should be enough to allow old (outdated/redundant) labelled_by relationships to be pruned (though it doesn't allow such relationships to be removed; I suspect this is unimportant).
  3. This is a hack, but might not work out too badly in practice: whenever a Node is replaced and the old one has a labelled_by property while the new Node doesn't, copy the property to the new Node. (The side effect is the same as with (2): updates cannot remove a labelled_by relationship.)
Final note

Most Node properties are not affected the same way, though some others may be (possibly radio box groups; I didn't investigate since Kas's widget model doesn't have the necessary data to set this anyway).

Lenguaje dominante
Rust
Estrellas
1.5k
Forks
117
Merge medio
6 h 5 min
PR fusionados (30 d)
19

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de AccessKit/accesskit

Todos los issues de AccessKit/accesskit

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.