View source for Talk:Accessibility/WebAccessibilityAPI

Very interesting. I think the accessible tree creation stuff is great. I worry a bit about how it overrides markup. There is a complex hierarchy between native html elements, aria, and now this. It becomes even more confusing for the developer how a name or role and other semantics are computed.

<code> > I don't have an answer for this but I lean towards to give the author absolute freedom, to ruin accessibility or to make it soar.</code>

From a perspective of authoring ATs with this, we need to have some larger architectural thoughts. For example, in FxOS it would be hard to keep the current top-level IPC design. instead, we may need to have a way to have scripts injected into each content process and yet somehow work in harmony and not bother each other (for example, hijacking input or speech output interruptions). Also, if we inject 3rd party scripts like that, we would need to have an appropriate security model.

<code> > agree, at this point there's no multiprocessing at all, I would avoid top level ipc approach at all costs. I hope Dominic will help here.</code>


Here are some random questions and thoughts in no particular order:
=== AccessibleElement ===
* What is the difference between the parent attribute and the logical parent relationship? Is it like aria-owns?

<code> > yes or flat trees, but I lean towards it should go away </code>

* What is a widget relationship? Is the widget an ancestor that is the root of the composite widget?

<code> > yes </code>

=== AccessibleValue Pattern Example ===
* How would one set the value or step up/down? via a method in the pattern or through actions?

<code> > I'd say you have to do this via actions and interactions </code>

* I guess this question should be more generalized: When does something fit a pattern or an action?

<code> > no answer yet, these are just concepts we may need, let's see how it evolves :) </code>

=== Actions ===
* I like how focus is folded into these methods.

<code> > cool, agree :) </code>

* I would harmonize with IndieUI.

<code> > I need your help with it </code>

* How can you have two 'activate' actions if ActionSet is a name/object mapping?

<code> > maybe it's rudiment from previous edits, I dont' recall we had two 'activate' actions</code>

* Additional actions:
** Zoom
** Drag and drop?
** expand/collapse
** select/unselect
** check/uncheck
** undo/redo
**  value step up/down

<code> > +1 for zoom, drag/drop, other actions are control dependent, I think they will provide them</code>

* The relationship between interactions and actions is confusing, both a AccessibleElement.interactions attribute, and one for each action? Does the sum of all the action interactions equal the set of top-level interactions?

<code> > action is a property of accessible, interfaction is a way to trigger the action from a device. answer to question is yes. how it can be improved? </code>

=== Traversal ===
I'm still wrapping my head around this proposal, it seems very different than what we have, and has potential. But really hard to concretetly understand how our current current design would functionally map to this.

<code> > I don't yet like the proposal, it has to be nicer. I didn't figure out yet how </code>

* Does a move() call change the 'anchor' attribute? Could it also change the wherebit? How?

<code> > yes, those anchor and wherebit is description of the position, if position is moved then they are changed too </code>

* I don't see a common use case of cyclic forward/backward.

<code> > I thought about Firefox search :) we can remove it if not needed </code>

* How do you query an AccessiblePos for the offset of the position within the anchor's text? Do you always need another AccessiblePos to compare with?

<code> > Not sure I have nice idea, but you should be able to use offset number and wherebit to place position inside the text. I didn't catch you about comparison. Do you have some example of it? </code>

* I could see a use for AccessiblePos.clone() + AccessiblePos.move() to get move deltas.

<code> > what does + means here. can you give example? </code>

* Is this what you see as replacing nsIAccessibleText?

<code> > yes, I think we can make AccessiblePos nice enough to get rid AccessibleText </code>

* The document.position is changed by assigning to it a new AccessiblePos?, or by calling document.position.move()? If the latter, could the move() method change the wherebit?

<code> > I think both. It should be able to change wherebit as it describes the position </code>

* I am assuming that the cursor_moved event would provide the old AccessiblePos? Lets say we want to listen for cursor_change and outline the current position. For text nav, that would probably work well with doc.outline(oldPosition, newPosition). But what if we are navigating by roles like links? It will outline the entire area between the two links, no?

<code> > so you say we should have 'outline' in API (I wasn't sure about it :) ) I guess so. </code>

* I don't understand TextUnit.bit, is it related to the wherebit?

<code> > iirc it was about to move to next text attribute change <code>

* Can you pass null to getBoundingRect to get the bounds of the anchor?

<code> > we could do that I guess, however your position should be *at* the anchor to get its bounds </code>

* Like yura says, positionFromPoint needs a similar argument to pos.move(). Use cases: (1) Ignore layout containers. (2) Speak word or sentence under finger/pointer.

<code> > ok, we'll sort it out </code>

=== AccessibleSource Etc. ===
* I am assuming after you do canvas.addHitRegion that all the bounds methods would work on it, like outline(), getBoundingRect(), etc? Plus canvas.scrollPathIntoView()?

<code> > It has to</code>

* Speaking of scrolling, the relationship between layout, canvas and custom 'scroll' actions will be interesting.

<code> > in what sense? I guess canvas author should implement</code>

* The taxonomy extensibility is awesome.

<code> > awesome, you know I'm thinking that taxonomies and content may have different providers and that has to be awesome feature. You invent new markup, provide taxonomies for it and then you let anybody to use it. Thank you for feeback! Let me polish the draft a bit to address your comments and let's do another round</code>