Closed
Bug 279941
Opened 20 years ago
Closed 20 years ago
Expose forms in MSAA
Categories
(Firefox :: Disability Access, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
Details
(Keywords: access)
Attachments
(1 file)
1.17 KB,
patch
|
pkwarren
:
review+
bryner
:
superreview+
|
Details | Diff | Splinter Review |
Screen readers have features to navigate by "form"
This means we need to expose accessible objects for the form nodes.
Assignee | ||
Comment 1•20 years ago
|
||
Attachment #172471 -
Flags: review?(pkwarren)
Updated•20 years ago
|
Attachment #172471 -
Flags: review?(pkwarren) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #172471 -
Flags: superreview?(bryner)
Comment 2•20 years ago
|
||
Looks good to me, out of curiosity though which Screen readers have this
feature, and what on "form" is navigateable?
Plus when we have a situation like
<form></form> what happens with the Screen Reader in question?
Our DOM with Forms can be quite onerous in some cases, where we have form
controls (Input, etc.) sitting un-nested from the form element they work with,
as far as I understand the relevant code.
Assignee | ||
Comment 3•20 years ago
|
||
Window-Eyes has the feature, and they're adding capaibility to recognize this
MSAA role.
They know that the <form> elements may not always be placed correctly. The
prev/next form navigation goes to the beginning of each form -- the first
accessible element within that.
Updated•20 years ago
|
Attachment #172471 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Comment 4•20 years ago
|
||
Checking in nsAccessibilityService.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v <--
nsAccessibilityService.cpp
new revision: 1.123; previous revision: 1.122
done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•