This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the "Important Terms", "accessible object" is defined as: "A user interface object whose basic accessibility is exposed to assistive technology via a platform accessibility API. Accessible objects are included in the accessibility tree. MS UIA represents accessible objects as automation elements." I'm possibly getting a little nitpicky, but as I read it, and despite what the second sentence in the definition says, the first sentence makes an accessible object a UI object like that rendered visually in the browser, and something whose accessibility (it's not clear what that is) is delivered via the accessibility API. I'd like to suggest the following small change: "A user interface object as exposed to assitive technology via a platform accessibility API. Accessible objects are included in the accessibility tree. MS UIA represents accessible objects as automation elements." This would be consistent with the definition of "accessibility tree" where it says "Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API".
(In reply to Jason Kiss from comment #0) > In the "Important Terms", "accessible object" is defined as: There are a couple of aspects of this definition that could be improved. 1. Is a paragraph a user interface object? Paragraph elements have corresponding nodes in the accessibility tree. As such, there are accessible paragraph objects. And, if paragraphs are user interface objects, what sorts of things are not? If the concept (user interface object) is so broad as to not exclude anything, it's kind of useless. But, if it is so narrow as to exclude a paragraph, then its use in this glossary item is wrong. 2. Accessible objects are independent of markup languages since they are used in scenarios outside of browsers. They are also used in the context of exposing information about desktop UI. An accessible button associated with a, say, GTK+ Button widget is the same thing as an accessible button derived from WAI-ARIA role, states, and properties. 3. Related to 2. above, the use of "element" in "automation element" is not the same meaning as "element" in "DOM element". UIA automation elements are used for representing the desktop -- see http://msdn.microsoft.com/en-us/library/windows/desktop/ee684076%28v=vs.85%29.aspx. Using "UIA automation element" in this definition is confusing to someone who doesn't know the difference. I'd reword the definition thus: "Accessible object: A node in the accessibility tree of a platform accessibility API that exposes various states, properties, and events for use by ATs. In the context of, WAI-ARIA specifically, and markup languages in general, accessible objects correspond to and are the accessibility API representations of markup elements." How's that for "nit picky"? :-)
(In reply to Joseph Scheuhammer from comment #1) > I'd reword the definition thus: > > "Accessible object: > > A node in the accessibility tree of a platform accessibility API that > exposes various states, properties, and events for use by ATs. In the > context of, WAI-ARIA specifically, and markup languages in general, > accessible objects correspond to and are the accessibility API > representations of markup elements." Way better! > How's that for "nit picky"? :-) I know it's not a competition, but I'd like to say that you win :) But I'll give it another go. 1. I think that what the "that" refers to in the first sentence is ambiguous. 2. While the various AAMs for the HTML and SVG markup languages do ultimately refer(defer?) to and leverage WAI-ARIA mappings where available, I think the definition should reverse the order in which they are presented. So I'd come back with: "Accessible object: A node in the accessibility tree of a platform accessibility API. In the context of markup languages (e.g., HTML and SVG) in general, and WAI-ARIA in particular, accessible objects correspond to, and are the accessibility API representations of, markup elements. Accessible objects expose various states, properties, and events regarding those markup elements for use by ATs." Your turn :)
(In reply to Jason Kiss from comment #2) > > Your turn :) I'm okay with reversing the order of WAI-ARIA vs markup languages. Still, and this is really really nit-picking, the existence of AAPIs (a11y trees, accessible objects, states, and properties) predate markup. The latest proposal can be read as if AAPIs were invented for markup and/or aria. But, in a sense, it's the other way around. AAPIs were created for exposing the desktop to ATs. When web authors began to implement rich internet applications in markup, the mapping of markup to the document related aspects of AAPIs was painfully inadequate. ARIA was a way of declaring how to expose things accurately. In fact early ARIA was a "port" of MSAA/IA2 concepts into markup attributes. With that in mind, here's my latest attempt: "Accessible object: A node in the accessibility tree of a platform accessibility API. Accessible objects expose various states, properties, and events for use by ATs. In the context of markup languages (e.g., HTML and SVG) in general, and WAI-ARIA in particular, markup elements and their attributes are represented as accessible objects." Your turn :)
A worthwhile nit-pick: that iteration is clear and succinct. I like it.
Replaced definition of gloassary entry as per discussion. https://github.com/w3c/aria/commit/fa256945d24a21c81462faba4a7ed3349ea87c65