Acessibilidade · Atualizado em abril de 2026

Declaração de acessibilidade

Name: RichTextEditor
Price: 129 USD
Author: Richscripts Inc.

A Richscripts Inc. tem o compromisso de tornar o RichTextEditor utilizável por todas as pessoas, seja qual for a tecnologia assistiva que alguém use para escrever e revisar documentos. Esta página informa qual é o nosso objetivo, o que funciona hoje e onde sabemos que ainda deixamos a desejar.

Objetivo de conformidade

O RichTextEditor tem como objetivo a conformidade com as Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.2, Nível AA. O editor é construído sobre contenteditable nativo, HTML semântico padrão e funções / atributos ARIA onde o HTML semântico sozinho não é suficiente.

Uma auditoria de acessibilidade feita por terceiros e um VPAT formal ainda não foram publicados. Até que haja evidências independentes, esta página é uma autoavaliação e lista explicitamente as lacunas que conhecemos.

O que funciona hoje

Operação por teclado (WCAG 2.1.1, 2.1.2, 2.4.3)

A barra de ferramentas é uma única parada de tabulação, seguindo o padrão de barra de ferramentas das ARIA Authoring Practices: Tab entra nela uma vez; depois, ← / → movem entre os botões e Home / End saltam para uma das extremidades. O foco volta para o último botão que você usou. Em RTL, a direção das setas acompanha a direção de leitura do documento.
Sem bloqueio do teclado (2.1.2). Tab mantém seu significado de edição dentro do conteúdo — recuar uma lista, ir para a próxima célula da tabela —, por isso a saída é uma tecla separada e documentada: Esc sai da área de edição e coloca o foco na barra de ferramentas, a partir da qual Tab continua pela página normalmente. Essa rota de saída é anunciada como parte do nome acessível da área de edição, então um leitor de tela a lê ao entrar, em vez de deixar o usuário adivinhar. Se um menu ou uma caixa de diálogo estiver aberto, Esc fecha esse elemento primeiro.
Todos os comandos da barra de ferramentas têm atalhos de teclado.
As caixas de diálogo prendem o foco; Esc as fecha e devolve o foco ao controle que as abriu.
As tabelas permitem navegar entre células com Tab e voltar com Shift+Tab.
Comandos de barra, @menções e a caixa de diálogo de IA funcionam inteiramente pelo teclado — sem necessidade de mouse.

Os botões da barra de ferramentas expõem nomes acessíveis via aria-label. Os comandos de alternância — negrito, itálico, sublinhado, alinhamento, listas, controle de alterações e os modos de visualização — expõem aria-pressed, espelhado do próprio estado ativo do editor, para que o valor anunciado nunca divirja do botão destacado. Os botões de menu expõem aria-haspopup e mantêm aria-expanded correto enquanto o menu abre e fecha.
As caixas de diálogo expõem role="dialog" com um aria-label que dá nome à caixa de diálogo; o foco fica dentro dela, e Esc a fecha e devolve o foco para onde ele estava. Na 2.6.12, dois painéis não são marcados como modais: o painel Insert Link aberto pela barra de ferramentas não tem aria-modal, e o Find and Replace define aria-modal="false". Ative o plugin de acessibilidade de caixas de diálogo para que o painel Insert Link receba role="dialog" e os campos dele recebam nomes.
O painel AI Review expõe a função region com um rótulo dinâmico; novas sugestões são anunciadas via aria-live="polite".
Comentários e sugestões do controle de alterações expõem rótulos por autor, para que os leitores de tela anunciem “Comment by Maya Patel”.
Os títulos no conteúdo do editor preservam a semântica de h1–h6; as listas preservam ul/ol/li.

Design visual (WCAG 1.4.3, 1.4.11, 1.4.12)

O tema padrão atende ao contraste de texto de 4.5:1 e ao contraste de interface de 3:1.
Os indicadores de foco ficam visíveis com contraste de 3:1 em relação às cores adjacentes e nunca são suprimidos pelas skins personalizadas incluídas no pacote.
Os layouts do editor respeitam as preferências de tamanho de texto do usuário — não há alturas fixas em pixels que cortem o texto quando o zoom do navegador está em 200%.
Nenhuma informação é transmitida apenas pela cor; a atribuição de alterações controladas sempre inclui um rótulo com o autor, além de uma cor.

Assistência de entrada (WCAG 3.3.1, 3.3.3)

As caixas de diálogo de upload e de URL de imagem descrevem os erros em linguagem simples, associados ao campo com problema via aria-describedby.
Ações destrutivas (excluir comentário, rejeitar sugestão) oferecem a opção Undo no painel de revisão.

Modelo de conteúdo

As imagens recebem texto alternativo pela caixa de diálogo Image; o alt é preservado ao colar do Word, do Excel e do Google Docs.
Os links preservam texto legível por humanos — “clique aqui” não é gerado automaticamente.
O HTML e o DOCX exportados preservam os níveis de título e a estrutura das listas; os leitores de tela que leem esses arquivos veem uma estrutura igual à do editor.
A exportação para PDF é marcada (tagged). Texto selecionável não é o mesmo que um documento acessível — um PDF sem marcação entrega à tecnologia assistiva um fluxo plano de palavras, sem títulos, semântica de listas, relações de tabela ou ordem de leitura garantida. O exportador vetorial grava uma árvore de estrutura completa (H1–H6, P, L/LI, Table/TH/TD com escopo de coluna, Figure com /Alt) e marca linhas, bordas e cabeçalhos corridos como artefatos, para que fiquem fora da ordem de leitura. Veja por que um PDF pesquisável e um PDF acessível são recursos diferentes e como o PDF é escrito à mão para que o texto continue sendo texto.

Lacunas conhecidas

Acreditamos que a confiança se constrói com honestidade, não com uma declaração que soe perfeita. Estas são as áreas em que sabemos que ainda não atingimos o objetivo, e o que estamos fazendo em cada uma:

Auditoria de terceiros ainda não publicada. Esta declaração reflete apenas uma autoavaliação. Equipes de compras corporativas que exigem um VPAT formal devem tratá-lo como um requisito em aberto e entrar em contato conosco para obter o pacote atual de evidências de acessibilidade.
Cabeçalhos de tabela são sinalizados, não inferidos. O editor não supõe que a primeira linha seja uma linha de cabeçalho — supor errado transforma dados em cabeçalhos, o que é pior do que não mexer. O que ele faz é sinalizar a tabela: o verificador de acessibilidade aponta table-missing-header em qualquer tabela sem células de cabeçalho e oferece um reparo com um clique que promove a primeira linha a <th scope="col">, preservando o conteúdo e os atributos das células. Esse scope é o que é levado para o PDF marcado (TH com escopo de coluna) e para o .docx (uma linha tblHeader repetida), então uma única correção ajusta a tabela em todos os formatos de exportação. A lacuna que resta é que uma tabela criada sem cuidado continua inacessível até que alguém execute o verificador.
O editor de imagens (tui.image-editor) é uma dependência de terceiros; sua paleta de ferramentas não é totalmente acessível por teclado. Oferecemos uma alternativa simples de Upload para que os usuários possam pular o editor e ainda inserir imagens com texto alternativo.
A barra de ferramentas para dispositivos móveis é responsiva, mas não está otimizada para a navegação pelo rotor do VoiceOver / TalkBack. Está no roadmap de 2026, junto com o modo dedicado de barra de ferramentas para dispositivos móveis.

Tecnologias assistivas suportadas

Testamos as combinações a seguir antes de cada release. Problemas em qualquer uma delas bloqueiam o release.

Plataforma	Leitor de tela	Navegador
Windows 11	NVDA 2024.x	Chrome, Firefox, Edge (mais recentes)
Windows 11	JAWS 2024	Chrome, Edge (mais recentes)
macOS 14+	VoiceOver	Safari (mais recente)
iOS 17+	VoiceOver	Safari
Android 13+	TalkBack	Chrome (melhor esforço)

Atalhos de teclado

O Guia do usuário final documenta a referência completa de atalhos. Destaques:

Ctrl+B / I / U — negrito / itálico / sublinhado
Ctrl+K — inserir link
/ no início de uma linha — menu de comandos de barra
@ + nome — seletor de menções
Ctrl+Alt+M — adicionar comentário na seleção
Ctrl+Shift+E — ativar/desativar o controle de alterações
Ctrl+Space em uma seleção — Ask AI

Relatar um problema

Se você usa tecnologia assistiva e algo não funciona, queremos saber. Inclua:

A tecnologia assistiva que você usa (nome + versão)
Navegador e sistema operacional
O que você estava tentando fazer, o que aconteceu e o que você esperava
A URL ou um trecho de código, se você for um integrador

Envie um e-mail para accessibility@richtexteditor.com — nos comprometemos a dar uma primeira resposta em até dois dias úteis.

Histórico de versões. Esta declaração foi publicada pela primeira vez em abril de 2026. Ela é revisada a cada trimestre, junto com o nosso ciclo de releases; alterações relevantes são destacadas nas notas de versão do produto.