Claude gera aplicativos acessíveis

Durante a primavera e o verão, tenho testado diferentes ferramentas de IA quanto à sua capacidade de gerar interfaces de usuário acessíveis do Android. Esta postagem é o post final de testes da série. Escreverei um post de recapitulação para resumir todas as minhas descobertas. A broca também é a mesma para este teste – eu gerei um aplicativo Android com Claude e depois o testei com várias ferramentas, configurações e tecnologias de assistência. Vamos falar sobre o aplicativo que eu gerei. O aplicativo desta vez também fiz apenas uma rodada de testes. O motivo é semelhante ao dos testes anteriores com o cursor – a configuração. Eu não queria pagar US $ 20 por esta postagem de blog, por isso estou usando a versão gratuita, o que significa que vou precisar operar no aplicativo de Claude e usar o recurso de bate -papo. Não é ideal, mas faz o trabalho dentro dos limites dos meus testes. Então, em suma, gerei o código no bate-papo, criei um projeto Android no Android Studio, adicionei os arquivos necessários e coloquei o código neles. Prompt do prompt que eu dei para Claude foi: você pode gerar telas de interface do usuário para um aplicativo Android com compor JetPack, no qual o usuário pode acompanhar o esconderijo de seus tesouros e agulhas de tricô por tamanho e tipo? Ele deve conter as seguintes telas: tela inicial, onde o usuário pode adicionar fios e agulhas, uma tela de lista para fios, uma tela de detalhes para fios individuais, uma tela de lista para agulhas de tricô, uma tela de detalhes para agulhas de tricô. As informações a serem armazenadas sobre o YARN consistem no seguinte: Nome da marca, nome do fio, colorway, yarage em metros, peso de novelo, quantidade de novelos, imagem. As informações para agulhas de tricô consistem no seguinte: Nome da marca, tamanho de agulhas de tricô em mm, tipo (pontual único, pontual dupla, circular). O tipo deve ser um suspensão. As telas de aplicativos devem estar acessíveis para usuários com navegação alternativa (dispositivo de comutação, teclado, navegação por voz), bem como leitores de tela, e deve funcionar bem nas orientações verticais e de paisagem, bem como em tamanhos de fontes maiores. Deve seguir todas as melhores práticas do material3. Listou os aspectos de acessibilidade considerados. Aqui está a lista: descrições semânticas para todos os elementos interativos atribuições de função adequadas (botão, troca, etc.) descrições de conteúdo para leitores de tela O gerenciamento de foco com o suporte à navegação de teclado para suporte para grande escala de texto Modo de contraste Opção Opção de voz Controla o texto da touramento de lógica 4 Switter 4 Remunça 40 De complacência do traseiro 48 Complacção de lógica 4. Dispositivos Uma coisa engraçada é que, embora Claude tenha gerado uma AcessityExtensions.kt-File, ele não é usado em lugar nenhum. E oh meu, quantos redundâncias isso contém. Eu poderia escrever um post separado sobre isso. Portanto, embora essa lista tenha muitos pontos positivos, no contexto deste aplicativo, é principalmente apenas uma lista sem a implementação real dos pontos relevantes. A interface do usuário aqui está um pequeno vídeo de como o aplicativo acabou: devo dizer que gosto mais do que os outros aplicativos gerados, que pareciam cópias um do outro. Processo de teste Após a criação do aplicativo, executei um conjunto limitado de testes de acessibilidade manual no aplicativo. Usei minha dobra de pixels, pois tenho tudo para testar configurado. As ferramentas, as tecnologias assistivas e as configurações de acessibilidade com as quais testei o aplicativo foram: Acessibilidade Scanner Talkback Switch Access Acesso físico Acesso à voz Tamanhos de fontes grandes Os problemas que encontrei como eu esperava, o aplicativo não estava sem problemas de acessibilidade. Mais notavelmente, o problema familiar com descrições de conteúdo redundante estava presente e também alucinou alguns papéis semânticos. Vejamos os problemas mais de perto. As descrições redundantes de conteúdo estão aqui para ficar, infelizmente, como em todos os outros aplicativos, o aplicativo de Claude também tinha descrições de conteúdo redundantes. Aqui está um exemplo (eu omiti as partes irrelevantes) flutuationActionButton (… modificador = modificador …. Quando o FloatingActionButton possui o atributo ContentDescription e o texto dentro, o texto de acessibilidade para este componente é “Adicione um novo fio à coleção. Adicione um novo fio”. A solução seria omitir o modificador de semântica com o ContentDescription. O código de Claude leva a redundância ainda mais longe: para algumas descrições de conteúdo, também adiciona texto de ação redundante. Here’s one example, a card for displaying needle list items with texts within the Card: Card( modifier = Modifier .semantics { role = Role.Button contentDescription = “${needle.brandName} ${needle.type.displayName} ” + “needles, ${needle.sizeMillimeters} millimeters. ” + “Tap for details.” }, … ) { … } Digite o modo de saída de tela cheia do modo de tela cheia A descrição do conteúdo agora contém todas as mesmas informações que o conteúdo deste cartão. Ele já está exposto a serviços de acessibilidade, por isso é redundante adicioná -lo aqui. No entanto, ele também adiciona o texto “Tap For Detalhes”, que é redundante. O cartão, sendo um elemento clicável, já contém a semântica para transmitir que é clicável, portanto, não há necessidade de indicá -lo na descrição do conteúdo. Além disso, como é um item em uma lista, portanto, juntamente com a semântica da lista e a habilidade de cliques, não há necessidade de indicar que tocar em abrir os detalhes. Esse é um padrão em muitos aplicativos, por isso provavelmente é familiar para os usuários. E agora que estamos no tópico das descrições de conteúdo, é interessante como Claude adiciona conteúdoDescription para iconButtons com semântica, e não com, bem, o contentDescription-attribute: iconbutton (onClick = { / * TODO: edit yarn * /}, modifier = modificier.Semantics {thentdo * Icons.default.edit, contentDescription = null)} Digite o modo de saída de tela cheia de tela cheia, enquanto o conteúdoDescription não é redundante neste caso, a solução mais direta para definir seria a seguinte: iconbutton (OnClick = { / * TODO: editar YARN * /}) {icon (icling } Digite o modo de tela cheia de tela FullScreen Modo Faltando o agrupamento em detalhes na tela Os detalhes, o fio e a agulha, precisariam ser agrupados com os rótulos e valores para que possam ser lidos juntos. Agora, por exemplo, ler a linha com o rótulo “Brand” e sua marca exige que o usuário navegue por ambos para obter as informações. Com MergedEndants = True para o modificador de semântica, o usuário ouviria os dois juntos. Em código, parece: // detalherow.kt @compositable Fun DetailRow (…) {Row (modificador = modificador .Semantics (MergedEsCendants = true) {}, <- Adicionando o modo FullScreen Exit (Text = TEXT = …) (Text = Text = …)}}} Enter o modo Fullcreen Ext FullScreen Claude foi o primeiro a alucinar algo que me impediu de construir o aplicativo. Como mencionei, gerou um arquivo completo de acessibilidade Extensões.kt, cujo conteúdo não está em uso. Ele tinha um modificador de accessibleTextfield com role.textfield: fun modifier.accessIbleTextfield (etiqueta: string, valor: string, isRequired: boolean = false) = this.Semantics {contentDescription = if (isRequired) “$ Campeo de texto requerido”, role) {nsoldScription = role = Role = Role = Role = Role = Role = Role. Ao analisar a documentação da função, ela não tem a função de campo de texto. Além disso, toda a semântica aqui é um pouco redundante, pois o TextField Composable já os fornece. Nenhum suporte adequado para navegação de botões O problema final que vou discutir é que o aplicativo não suporta bem a navegação do botão. Você sabe, o modo de navegação, onde existem esses botões na parte inferior da tela – veja o vídeo acima na seção da interface do usuário. Ao aumentar a fonte e os tamanhos de exibição, o aplicativo não deixa espaço para a barra de navegação, e parte do conteúdo está escondida atrás da barra de navegação do sistema, como visto na figura abaixo: eu pessoalmente uso a navegação de botões (portanto, não a navegação por gestos) e, surpreendentemente, muitos aplicativos têm o mesmo problema. Em resumo, como mencionado anteriormente, gostei mais do aplicativo de Claude da perspectiva da interface do usuário. Do ponto de vista da acessibilidade, o aplicativo gerado não foi tão ruim – ele tinha problemas de acessibilidade, mas não tantos quanto, por exemplo, a primeira tentativa de Gêmeos. No entanto, foi a primeira vez em meus testes quando recebi algumas alucinações. O código alucinado não foi realmente usado pelo aplicativo, mas poderia ter sido. Os resultados não me surpreenderam. Cheguei ao ponto de saturação, então é hora de escrever o post de resumo para todos os testes que tenho executado nos últimos meses. Então, fique atento, isso está chegando. Links na postagem do blog

Fonte