Closed Bug 290260 Opened 20 years ago Closed 20 years ago

Allow xhtml2:role for XUL elements with no nsIAccessibleProvider implementation

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

Details

(Keywords: access)

Attachments

(1 file)

Any XUL element should be able to use XHTML2:role to create its accessible, even a <vbox> or some element that does not normally have an accessible object.
Attachment #180665 - Flags: review?(timeless) → review?(kyle.yuan)
Comment on attachment 180665 [details] [diff] [review] If no nsIAccessibleProvider, create generic accessible if xhtml2:role or tabindex is specified >Index: accessible/src/base/nsAccessibilityService.cpp >=================================================================== >RCS file: /cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v >retrieving revision 1.135 >diff -p -u -5 -r1.135 nsAccessibilityService.cpp >--- accessible/src/base/nsAccessibilityService.cpp 4 Apr 2005 17:26:55 -0000 1.135 >+++ accessible/src/base/nsAccessibilityService.cpp 14 Apr 2005 02:42:41 -0000 >@@ -1796,16 +1796,23 @@ NS_IMETHODIMP nsAccessibilityService::Ge > } > else if (!content->IsContentOfType(nsIContent::eHTML)) { > // --- Try creating accessible non-HTML (XUL, etc.) --- > // XUL elements may implement nsIAccessibleProvider via XBL please add some punctuation ^ > // This allows them to say what kind of accessible to create please add some punctuation ^ >+ // Non-HTML elements must have an nsIAccessibleProvider, tabindex please add some punctuation ^ >+ // or XHTML2 role or they're not in the accessible tree. ^^^^^^^^^^^^^ |they won't be| (reflected?) > nsCOMPtr<nsIAccessibleProvider> accProv(do_QueryInterface(aNode)); >- // Non-HTML elements must have an nsIAccessibleProvider or they're not in >- // accessible tree. >- if (!accProv) >+ if (accProv) { >+ accProv->GetAccessible(getter_AddRefs(newAcc)); >+ } >+ else if (content->HasAttr(kNameSpaceID_None, nsAccessibilityAtoms::tabindex) || >+ content->HasAttr(kNameSpaceID_XHTML2_Unofficial, nsAccessibilityAtoms::role)) { >+ newAcc = new nsAccessibleWrap(aNode, aWeakShell); // Create generic accessible what happens when this fails? >+ } >+ else { > return NS_ERROR_FAILURE; >- accProv->GetAccessible(getter_AddRefs(newAcc)); >+ } > } > else { > // --- Try creating accessible for HTML --- > frame->GetAccessible(getter_AddRefs(newAcc)); // Try using frame to do it > if (!newAcc) {
>>+ newAcc = new nsAccessibleWrap(aNode, aWeakShell); // Create generic accessible > what happens when this fails Dealt with at the end of this method where via | return InitAccessible(newAcc, aAccessible); | That handles a null newAcc by returning an error.
Comment on attachment 180665 [details] [diff] [review] If no nsIAccessibleProvider, create generic accessible if xhtml2:role or tabindex is specified Perhaps Kyle is busy?
Attachment #180665 - Flags: review?(kyle.yuan) → review?(Louie.Zhao)
Blocks: deera11y
Comment on attachment 180665 [details] [diff] [review] If no nsIAccessibleProvider, create generic accessible if xhtml2:role or tabindex is specified r=kyle
Attachment #180665 - Flags: review?(Louie.Zhao) → review+
Attachment #180665 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180665 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attachment #180665 - Flags: approval-aviary1.0.4?
Did you mean to ask for approval-aviary1.1 instead of 1.0.4?
Attachment #180665 - Flags: approval-aviary1.0.4? → approval1.8b2?
Comment on attachment 180665 [details] [diff] [review] If no nsIAccessibleProvider, create generic accessible if xhtml2:role or tabindex is specified a=asa
Attachment #180665 - Flags: approval1.8b2? → approval1.8b2+
Enter passphrase for key '/home/aleventhal/.ssh/id_dsa': Checking in nsAccessibilityService.cpp; /cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v <-- nsAccessibilityService.cpp new revision: 1.137; previous revision: 1.136 done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Should we really be adding support for a specification that's not yet in CR and explicitly says: # It should in no way be considered stable, and should not be normatively # referenced for any purposes whatsoever. - http://www.w3.org/TR/2004/WD-xhtml2-20040722/ Have you discussed implementing this in a released implementation with the HTML working group? Are they comfortable with it?
David, here's your answer: <Rich> Firefox would like to use the role attribute for XUL in the 1.1. build <Rich> is there a problem with this <Rich> ? <Rich> They would be using the WAI taxonomies for the role attributed <Rich> attribute <Rich> I view this and the implementation of xforms as the steps toward xhtml2 <Steven> Using xhtml:role? <Rich> yes <Steven> That's allowed <Steven> All attributes in Common are usable in other markup languages <mdubinko> what is the XUL connection again? <Rich> ok. the concern was that we were not at CR and whether you would be concerned <Steven> As long as they use the right namespace
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: