Expose spelling and grammar errors (is_spelling_error, is_grammar_error) to screen readers

Đang mở
  • Có gì không ổn?
#847 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
56/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
accessibility, backend

Hướng nghiên cứu

Start with inherited flags and text attribute comparisons in accesskit_consumer/src/text.rs, then trace the Windows, AT-SPI, and macOS text adapters named in the issue. Check how each adapter represents spelling and grammar errors and how format units split at their boundaries. Done means both flags reach the platform APIs described, with tests for inherited flags, format unit boundaries, and Windows ranges inside, around, and across an error.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

I'm Claude, an AI assistant, writing on behalf of the owner of this account, who asked me to report this. I checked each statement below against the sources it links to, pinned to the commits I read. There's no code with this, only the problem and a plan.

Problem

Node has is_spelling_error and is_grammar_error (lib.rs#L1967-L1970), but nothing reads them: they appear nowhere in accesskit_consumer or in the adapters. So when an editor marks a misspelled word on its text run, nothing reaches a screen reader on any platform:

  • Windows: GetAttributeValue returns the reserved "not supported" value for every attribute it doesn't list, so UIA_AnnotationTypesAttributeId is never answered (text.rs#L419-L490).
  • macOS: accessibilityAttributedStringForRange: adds no misspelled attribute (node.rs#L855).
  • AT-SPI: the text attribute table has no invalid entry (text_attributes.rs#L68-L79).

Invalid::Spelling and Invalid::Grammar (aria-invalid) aren't read by any adapter either.

What this costs a user, with NVDA on Windows as the example. NVDA takes errors from UIA_AnnotationTypesAttributeId (NVDAObjects/UIA/__init__.py#L312-L327). That attribute is what makes it say "spelling error" while reading and with NVDA+F. It also drives the W key in browse mode, which moves to the next error (browseMode.py#L1218-L1220). W walks the document one TextUnit_Format at a time and checks the attribute on each unit (UIAHandler/browseMode.py#L126-L150). Today, in an AccessKit app, NVDA never reports an error and W finds none.

What Chromium does

Proposed plan

  1. Consumer: read both flags the way is_italic is read, as inherited flags (text.rs#L1427-L1429). Then Range gets is_spelling_error() and is_grammar_error() returning RangePropertyValue, and a flag can sit on a run or on a container of runs. Also add both to text_attributes_differ (text.rs#L1432-L1445), so that a format unit starts and ends at an error, which is what NVDA's W relies on.
  2. Windows: answer UIA_AnnotationTypesAttributeId:
    • with a VT_ARRAY | VT_I4 holding AnnotationType_SpellingError and/or AnnotationType_GrammarError;
    • with an empty array outside errors;
    • with the reserved mixed value for a range that is partly in an error, as Chromium does.
  3. AT-SPI: add invalid to the attribute table, with spelling, grammar or spelling,grammar.
  4. macOS: add NSAccessibilityMarkedMisspelledTextAttribute for spelling errors.

Tests:

  • the per-flag tests that inherited_flags! already generates;
  • a consumer test that format units start and end at an error;
  • a Windows test that reads the attribute inside an error, around it, and across its edge.

Side note, from reading the same code: is_italic isn't in text_attributes_differ either. So a run that differs from the one before only in being italic doesn't start a format unit, and a format unit over both reads IsItalic as mixed. That may deserve a fix of its own.

If it helps, I can check a change against NVDA 2026.2 on Windows and report what it reads.

Ngôn ngữ chính
Rust
Star
1.5k
Fork
133
Merge trung bình
16 giờ 45 phút
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của AccessKit/accesskit

Tất cả issue của AccessKit/accesskit

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.