Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Case for revised data model: labelled_by

Aberta
#583 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
rust
Domínio
accessibility

Direção de pesquisa

Comece rastreando o modelo de dados de Node e o caminho de atualização parcial da árvore shadow de acessibilidade, concentrando-se em como labelled_by é atribuído e preservado quando um Node é substituído. A issue apresenta três designs possíveis, mas não seleciona nenhum; para considerá-la concluída, seria necessário chegar a um acordo sobre um modelo de dados e definir o comportamento para manter ou remover as relações labelled_by.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).

Linguagem predominante
Rust
Estrelas
1.5k
Forks
127
Merge médio
2d 10h
PRs com merge (30d)
14

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de AccessKit/accesskit

Todas as issues de AccessKit/accesskit

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.