Re: [Accessibility-ia2] HTML elements mapping

[Alexander Surkov]

On Thu, Jan 4, 2018 at 5:35 PM, James Teh <j...@mozilla.com> wrote:

> On Fri, Jan 5, 2018 at 7:37 AM, Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> We could add new roles if we have to, however it would make IA2 unique,
>> since no other API seems use roles for elements like HTML:q.
>>
> That's true, but ATK does have a role for blockquote, for example, and I
> think IA2 should too.
> I'm actually not convinced we need a special role for  anyway. While I
> guess it does have some semantic value, most browsers end up rendering
> quotes around it by default... and I don't imagine many authors would
> change this (apart from perhaps changing the marks used).
>
> It is a separate issue, but how do you feel about introducing a basic
>> taxonomies support: for example, roles() method that returns a string
>> containing all comma separated roles, for example, "q,text" for HTML:q
>> element? That would save us from usual torments, we deal with
>> occasionally, whether we should or should not add a new role, which
>> involves IDL changes and not backward compatible.
>>
> I don't see much practical advantage to this as compared with the
> xml-roles object attribute, which is already in wide-spread use. I guess a
> new method is theoretically cleaner (and I might agree if we were talking
> about designing from scratch), but as I see it right now, it only serves to
> create yet another mechanism for roles.
>

I see the point. Just in case, I started a new thread on this [1] to branch
this discussion off. It probably has some momentum.

[1]
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2018-January/002232.html


>
> Jamie
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] role taxonomies

[Alexander Surkov]

Hey.

On a regular bases we keep returning to a discussion, whether we should add
a new role into IAccessible2 role family or not, often struggling to find
balance: whether new semantics deserves a new role or we can live with
existing ones.

Adding a new role is not only answering to a question, whether we deal with
new semantics or not. It is always a pain because:
* It's not backward compatible change, which means that screen readers has
to adopt it to work with new semantics properly, which leaves an element
totally inaccessible for a while.
* We need to change IDL, which is one more obstacle on the role adoption
way.

As a hot-fix of the problem, Gecko introduced xml-roles object attribute (a
long time ago) to expose new semantics, while using IAccessible2 role as a
fallback for older screen readers. For example, HTML:input@type="search"
has xml-roles="searchbox" and ENTRY for a role.

xml-roles object attribute was never adopted officially by IAccessible2
standard, and has a restriction of a single role per element, which works
well for the majority of cases, but doesn't really suit for multi-level
role taxonomies, we may benefit from. For example, a tree grid element
hierarchy cannot be exposed via combination of IA2 role and xml-roles
object atttribute: "treegrid -> tree, grid -> control -> group".

I suggested in [1] to add a new method roles() for IAccessible2_X
interface, which is supposed to return a string of all roles that an
element may have, including base roles. For example, HTML:progress element
might be exposed as "group,meter,progress". If we wanted to support
multiple inheritance, then we could still be able flatten the tree in some
way,  for example: "treegrid,tree,group;grid,group".

The benefits of the approach are:
* we can build IAccessible role taxonomy without keeping changing IDLs,
which is simple and backward compatible;
* AT gets easy parsable string, which brings communication between a
browser and AT to a minimum, and allows to fetch all role information in
one call.

I buy the argument that IA2 role + xml-roles works in majority of cases,
and each new method has own adoption curve; but curious, if we can find a
flexible and nice solution to stop returning over and over to a new role
dilemma, and turn the solution into standard.

Thank you.
Alexander.


[1]
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2018-January/002229.html
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] HTML elements mapping

[Alexander Surkov]

On Wed, Jan 3, 2018 at 8:51 PM, James Teh <j...@mozilla.com> wrote:

> Hi Alex,
>
> If all of these things have semantic value, we really should be creating
> new roles for them. However, we probably don't have time to make that
> happen given the status of the mappings, so the below answers assume we
> don't create new roles.
>

We could add new roles if we have to, however it would make IA2 unique,
since no other API seems use roles for elements like HTML:q.

It is a separate issue, but how do you feel about introducing a basic
taxonomies support: for example, roles() method that returns a string
containing all comma separated roles, for example, "q,text" for HTML:q
element? That would save us from usual torments, we deal with occasionally,
whether we should or should not add a new role, which involves IDL changes
and not backward compatible.


> Note that in IA2, blockquote doesn't have a role either, which is ugly and
> needs to be fixed. So, I think we need to have a discussion about creating
> a whole bunch of new roles and revising a future version of the mappings to
> include them.
>
> On Wed, Jun 21, 2017 at 4:48 AM, Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> * HTML:q [1]
>> The spec says [2] to use ROLE_SYSTEM_TEXT which contains
>> ROLE_STATIC_TEXT for quotes and ROLE_SYSTEM_TEXT for text itself in
>> children.
>>
> Ideally, I think the MSAA role should be ROLE_SYSTEM_STATICTEXT for the
> element and its children here. I've always felt that ROLE_SYSTEM_TEXT was
> really meant for navigable text; e.g. 
>
However, for the element itself, that doesn't fit the convention adopted
> elsewhere in the spec... and IA2 clients will ignore the MSAA role in
> favour of the IA2 role anyway. So, we should probably leave this as
> ROLE_SYSTEM_TEXT for the element itself for now.
> For the children, I think they should all be ROLE_SYSTEM_STATICTEXT for
> the reason given above.
> Note that Gecko exposes text leaves as ROLE_SYSTEM_TEXT, which conflicts
> here. In contrast, Chrome uses ROLE_SYSTEM_STATICTEXT (as per my suggestion
> to them).
>

MSAA says that ROLE_SYSTEM_TEXT is "The object represents selectable text
that allows edits or is designated as read-only", while
ROLE_SYSTEM_STATICTEXT is "The object represents read-only text, such as
labels for other controls or instructions in a dialog box. Static text
cannot be modified or selected". So it doesn't look like MSAA conforming if
we used STATIC_TEXT for text nodes, since they all are selectable as a
rule. I think this is a reason why Gecko uses STATIC_TEXT only for things
like list item bullets, and TEXT for all other text nodes. I agree though
that SYSTEM_TEXT for both HTML:input and a text child of HTML:p also may
appear confusing.


> * HTML:ruby [3]
>>
>> The spec suggests [4] to use ROLE_SYSTEM_TEXT.
>>
> As above, I think this should ideally be STATICTEXT, but I guess we should
> leave this as is for now.
>

Looks good with me. Btw, we also we have more HTML elements like this, for
example, HTML:abbr.


>
>> * @multiple on input@type"file"
>> Spec says nothing [6]. Any suggestions on its mapping?
>>
> There's no "good" mapping at present.
> I'm wondering whether we really need to expose this. As far as I know,
> there's no (non-a11y) UX pattern for exposing this either apart from
> changing the text; e.g. Firefox says "No file selected" or "No files
> selected".
> My first thought was to abuse STATE_SYSTEM_MULTISELECTABLE. That is not a
> great fit because it's meant for containers which can accept multiple
> selection, but it kinda sorta works. The question is whether any existing
> client will be confused by this. NVDA won't be, but I don't know about
> others.
> Otherwise, we'd need to create a new state or perhaps an object attribute,
> perhaps called multivalue.
> But where do we put it? On the button or the text frame? And how does the
> client deal with this since there's no indication that it's for a file
> chooser?
> My feeling on this right now is that we shouldn't expose it specially.
>

Sounds good with me. As far as I know there's no any indication that the
control supports multiple file selection, until the user tries to make
multiple selection.


>
> I also see that  has IA2_ROLE_TEXT_FRAME. The convention seems to be
> that TEXT_FRAME is used for inline content, whereas block content uses
> SECTION or PARAGRAPH. Chrome already uses PARAGRAPH, but the mappings say
> SECTION for ATK. My initial feeling was SECTION.
>

SECTION seems like a good match for this one.


>
> Jamie
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] ARIA set-size=-1 mapping

[Alexander Surkov]

Sounds good with me. Thanks! I'll come back with this accord to ARIA group.

On Thu, Aug 3, 2017 at 8:02 PM, James Teh <ja...@nvaccess.org> wrote:

> Hi.
> I don't think we need a state for this. IAccessible2::groupPosition
> already exists and it doesn't define meanings for -1, so I think we could
> just return similarItemsInGroup as -1.
>
> Jamie
>
> On Fri, Aug 4, 2017 at 8:03 AM, Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> Hey.
>>
>> ARIA has aria-setsize="-1" to point out that a set of items has unknown
>> size [1]. ATK uses ATK_STATE_INDETERMINATE [2], which also used for
>> tri-state checkboxes.
>>
>> So do we want to IA2-extend MSAA's SYSTEM_STATE_MIXED, used for tri-state
>> checkboxes, to this case? Should we go with a new IA2's INDETERMINATE state?
>>
>> Thanks!
>> Alexander.
>>
>>
>> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-setsize
>> [2] https://developer.gnome.org/atk/stable/atk-AtkState.html#AtkStateType
>> [3] https://github.com/w3c/aria/issues/567
>>
>> ___
>> Accessibility-ia2 mailing list
>> Accessibility-ia2@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>>
>>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] ARIA set-size=-1 mapping

[Alexander Surkov]

Hey.

ARIA has aria-setsize="-1" to point out that a set of items has unknown
size [1]. ATK uses ATK_STATE_INDETERMINATE [2], which also used for
tri-state checkboxes.

So do we want to IA2-extend MSAA's SYSTEM_STATE_MIXED, used for tri-state
checkboxes, to this case? Should we go with a new IA2's INDETERMINATE state?

Thanks!
Alexander.


[1] https://www.w3.org/TR/wai-aria-1.1/#aria-setsize
[2] https://developer.gnome.org/atk/stable/atk-AtkState.html#AtkStateType
[3] https://github.com/w3c/aria/issues/567
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] HTML elements mapping

[Alexander Surkov]

Hey.

HTML-a11y mapping spec needs to check/update its IA2 mapping for a bunch of
HTML elements.

* HTML:q [1]

indicates that the enclosed text is a short inline quotation


The spec says [2] to use ROLE_SYSTEM_TEXT which contains ROLE_STATIC_TEXT
for quotes and ROLE_SYSTEM_TEXT for text itself in children.

* HTML:ruby [3]

> represents a ruby annotation. Ruby annotations are for showing
> pronunciation of East Asian characters.
>

The spec suggests [4] to use ROLE_SYSTEM_TEXT.

* @multiple on input@type="file"

indicates whether the user can enter more than one value.
>

Spec says nothing [6]. Any suggestions on its mapping?

Thanks!
Alexander.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/q
[2] https://w3c.github.io/html-aam/#el-q
[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ruby
[4] https://w3c.github.io/html-aam/#el-ruby
[5]
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-multiple
[6] https://w3c.github.io/html-aam/#att-multiple-input
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] RELATION_MEMBER_OF versus RELATION_NODE_PARENT_OF

[Alexander Surkov]

Hi, Joanie.

As I understand it, "node parent of" / "node child of" are inverse
relations, used to reflect the hierarchy when it is mismatched with the
accessible tree, for example, for flat trees or aria-owns in certain
implementations as you pointed it out.

"member of" is an abstract relation, used to describe membership-like
relations, and doesn't define the accessible tree hierarchy. Also unlike
"node child of" the "member of" relation is 1 to many relation.

Firefox uses 'member of' relation to point to an atomic region the element
belongs to. There's no other cases in Firefox afaik.

Thanks.
Alex.


On Fri, May 19, 2017 at 7:06 AM, Joanmarie Diggs  wrote:

> Hey all.
>
> Both ATK/AT-SPI2 and IA2 have "member of" and "node parent of"
> accessible relation types. I'm wondering if both are needed.
>
> If memory serves me, "node parent of" was added as an after-the-fact
> inverse relation type for the "node child of" relation type. It's used
> in Gtk+ for trees and tables, and in ARIA implementations to map
> aria-owns. It seems to me that "node parent of" could also be used for
> whatever purpose "member of" was intended for. But I say that as someone
> who isn't seeing "member of" used on her platform.
>
> Given that some folks desire ATK/AT-SPI2 and IA2 be harmonized wherever
> possible, I figured I would ask if "member of" serves some helpful
> purpose in IA2 implementations. If so, I'm hoping your concrete examples
> will help me improve the ATK and AT-SPI2 docs.  If not, should
> we consider deprecating it on our respective platforms?
>
> Thanks in advance for your thoughts and insight on this matter!
> --joanie
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

[Alexander Surkov]

We definitely should reach out our AT vendor contacts, pointing to the
summary of the thread, but in general I'd say it's reasonable to expect
that all IA2 consumers/implementers follow the list.

On Wed, Feb 22, 2017 at 2:39 AM, Dominic Mazzoni 
wrote:

> Great summary. I think the next step is to bring this to other AT vendors
> and see if this will work for everyone.
>
> On Tue, Feb 21, 2017 at 10:13 PM James Teh  wrote:
>
>> Hi guys,
>>
>> Sorry for the delay in responding. I needed to find time to sit down and
>> digest all of this. :)
>>
>>
>>1. Alex, your (thorough) outline of how this should work looks
>>correct to me and is what I intended. Thanks.
>>2. Moving to the first cell in the table is easily achieved by
>>navigating the tree.
>>3. Moving to the last cell in the table isn't so easy if there is a
>>cell in an earlier row with a row span.
>>   - For example, consider a 2 x 2 table where r1c2 spans both r1 and
>>   r2. Technically, the last cell in the table is actually r2c2, which is 
>> the
>>   same as r1c2. That accessible will only appear in the row for r1.
>>   Therefore, navigating to the last accessible in the tree will give you 
>> r2c1.
>>   - You can't even just ask for cellAt(nRows, nCols) because nRows
>>   and nCols might be greater than the last row/column index. For example,
>>   there might be 2 x 2 cells, but aria-rowcount and aria-colcount might 
>> be
>>   set to 3 (if you can have gaps in the middle of a table, why not at the
>>   end?).
>>4. We have similar problems when navigating to the first cell in a
>>row. If a cell in a previous row had a row span, first child on the row is
>>not sufficient.
>>5. Navigating to the first cell in a given column is complicated as
>>has already been described, but it's even worse if you take col span into
>>account.
>>6. I think I like the idea of having magic values for cellAt. -1
>>means first, -2 means last. These should account for row/col span. You can
>>then do:
>>   - First cell in table: (-1, -1)
>>   - Last cell in table: (-2, -2)
>>   - First cell in row r: (r, -1)
>>   - Last cell in row r: (r, -2)
>>   - First cell in column c: (-1, c)
>>   - Last row in column c: (-2, c)
>>7. Regarding a table with lots of holes, I agree this is confusing
>>enough that the benefits of table navigation start to be lost. The user
>>would probably end up just navigating linearly. In IA2 terms, they would
>>follow the tree/text interface.
>>8. It's worth noting that while we do now have relationTargetsOfType,
>>there's actually a benefit to fetching all relations at once. Screen
>>readers in particular tend to need all (or most) of the available
>>information for an object to report it well. If we know we're eventually
>>going to need all relations, we may as well fetch them all ahead of time,
>>particularly if we're doing so cross-process.
>>9. Alex, I'm confused about your comment concerning relations not
>>being strings. They *are* strings at present. Sure, they're constants in
>>the IDL, but we don't require everyone to build new binaries just to use a
>>new relation; they can define the constant themselves, even if 
>> temporarily.
>>
>>
>> I think I got everything! :)
>>
>>
>> Thanks!
>>
>> Jamie
>>
>>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

[Alexander Surkov]

Hey, here's some commenting inline.


On Wed, Feb 22, 2017 at 1:13 AM, James Teh  wrote:

> Hi guys,
>
> Sorry for the delay in responding. I needed to find time to sit down and
> digest all of this. :)
>
>
>1. Alex, your (thorough) outline of how this should work looks correct
>to me and is what I intended. Thanks.
>2. Moving to the first cell in the table is easily achieved by
>navigating the tree.
>3. Moving to the last cell in the table isn't so easy if there is a
>cell in an earlier row with a row span.
>   - For example, consider a 2 x 2 table where r1c2 spans both r1 and
>   r2. Technically, the last cell in the table is actually r2c2, which is 
> the
>   same as r1c2. That accessible will only appear in the row for r1.
>   Therefore, navigating to the last accessible in the tree will give you 
> r2c1.
>   - You can't even just ask for cellAt(nRows, nCols) because nRows
>   and nCols might be greater than the last row/column index. For example,
>   there might be 2 x 2 cells, but aria-rowcount and aria-colcount might be
>   set to 3 (if you can have gaps in the middle of a table, why not at the
>   end?).
>4. We have similar problems when navigating to the first cell in a
>row. If a cell in a previous row had a row span, first child on the row is
>not sufficient.
>5. Navigating to the first cell in a given column is complicated as
>has already been described, but it's even worse if you take col span into
>account.
>6. I think I like the idea of having magic values for cellAt. -1 means
>first, -2 means last. These should account for row/col span. You can then
>do:
>   - First cell in table: (-1, -1)
>   - Last cell in table: (-2, -2)
>   - First cell in row r: (r, -1)
>
>
If a row is spanned, then would this return a cell from previous row, that
the spanning started from, or it returns a first available cell in the row
or returns null?


>
>- Last cell in row r: (r, -2)
>   - First cell in column c: (-1, c)
>   - Last row in column c: (-2, c)
>1. Regarding a table with lots of holes, I agree this is confusing
>enough that the benefits of table navigation start to be lost. The user
>would probably end up just navigating linearly. In IA2 terms, they would
>follow the tree/text interface.
>
>
Would it be nice to have an iterator interface on a table/cell instead of
providing a low level methods? The iterator can keep the navigational
context, and figure out what the next/prev/up/down/first/last cells are.


>
>1. It's worth noting that while we do now have relationTargetsOfType,
>there's actually a benefit to fetching all relations at once. Screen
>readers in particular tend to need all (or most) of the available
>information for an object to report it well. If we know we're eventually
>going to need all relations, we may as well fetch them all ahead of time,
>particularly if we're doing so cross-process.
>
>
It's unfortunate for a server's performance, and probably a client's
performance as well, because as long as you cached something, then you have
to keep it updated.


>
>1. Alex, I'm confused about your comment concerning relations not
>being strings. They *are* strings at present. Sure, they're constants in
>the IDL, but we don't require everyone to build new binaries just to use a
>new relation; they can define the constant themselves, even if temporarily.
>
>
Thanks, I should read the IDL before making the statements :) I was
confused with we have the predefined constants.


>
> I think I got everything! :)
>
>
> Thanks!
>
> Jamie
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

[Alexander Surkov]

I referred to relations as a concept, which is exposed via
IAccessibleRelation or accNavigate.

IA2 relations don't have to be expensive, IA2 provides
relationTargetsOfType which returns multiple targets for a relation type
and lighter version of IAccessibleRelation array. On the other hand,
IAccessibleRelation can be instantiated lazily too. Or do you mean that
some AT run through relations over and over and you have to maintain
up-to-dated data?

Magic values should work, however cellAt(0, n) or cellAt(n, 0) is either
confusing or not helpful if initial cells are missed. We could do negative
values (for example, -1 and -2 as we do for offsets), which is less
intuitive but less ambiguous.

Alex.


On Wed, Feb 15, 2017 at 2:48 PM, Dominic Mazzoni <dmazz...@google.com>
wrote:

> On Wed, Feb 15, 2017 at 11:25 AM Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> On Wed, Feb 15, 2017 at 2:06 PM, Dominic Mazzoni <dmazz...@google.com>
>> wrote:
>>
>> Agreed, finding the first or last cell in a row isn't hard. But finding
>> the first or last cell in a column is hard, and some AT already have a
>> command for that.
>>
>>
>> Got it. We of course can have extra pair of relations for this. I wish we
>> had strings for relations as we have for object attributes. That would free
>> us from changing IDL over and over.
>>
>
> If you're talking about IAccessibleRelation, aren't relations expensive?
> We have to keep track of all of the relations for each accessible object
> currently because you can iterate over them and get one by index. I'd
> prefer a new constant for accNavigate if that's allowed, otherwise maybe
> adding new magic constants that you could use with cellAt().
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

[Alexander Surkov]

I think I miss why AT can't rely on accessible tree structure to fetch
first or last cell in a row. If AT has a row, then
NAVDIR_FIRSTCHILD/NAVDIR_LASTCHILD can be used on the row.

It may be tricky though to navigate through table with holes by means of
UP/DOWN/LEFT/RIGHT relations. For example, say, we have a table 3x3 with
cells at the diagonal only:

| cell  | hole | hole |
| hole | cell  | hole |
| hole | hole | cell  |


If AT is at (3, 3) cell, then the closest cell with be a cell at (2,2).
Neither of UP/DOWN/LEFT/RIGHT/FIRST/LASTCHILD/NEXT/PREVSIBLING relations
seems helpful here.





On Wed, Feb 15, 2017 at 12:35 PM, Dominic Mazzoni via Accessibility-ia2 <
accessibility-ia2@lists.linuxfoundation.org> wrote:

> Yes, that's how I'd interpret it too.
>
> I like this because it essentially frees each AT from needing to reason
> about complex table structures. The browser takes care of understanding the
> virtual table structure and exposes it via a more straightforward API to
> the AT.
>
> One question, though: How would the AT move to the first or last cell in
> the table, or the first cell in a row or column?
>
> I guess moving to the first cell in the table would be easy just by
> following the tree structure rather than using IAccessibleTable.
>
> Moving to the first or last cell in the current row or column seems a lot
> harder, though, because a virtual table might not start anywhere near a row
> or column index of 1. Perhaps we should add some convention, for example
> cellAt(n, 0) means the first column in row n, and cellAt(0, n) means the
> first row in column n. Any value larger than the largest row or column
> would move to the last row or column, so passing MAX_INT would work. Does
> that seem like a good idea?
>
> The other alternative would be to extend accNavigate with additional
> constants to move to the first or last cell in a row/column.
>
>
>
> On Wed, Feb 15, 2017 at 9:20 AM Alexander Surkov <asur...@mozilla.com>
> wrote:
>
>> Hey, sorry about the delay.
>>
>> NAV_UP/DOWN/LEFT/RIGHT relations look reasonable on a cell object both
>> in context and out of context of aria-rowcol stuff.
>>
>> Please correct me if I'm wrong in assumptions:
>> * NAV_UP/DOWN/LEFT/RIGHT on each cell object that returns
>> up/down/left/right cell corresponding to a table structure, i.e.
>> up/down moves through a column and returns a closest cell of the same
>> column if any, left/right moves in a row;
>> * IAccessibleTable2::nColumsn/nRows return aria-col/rowcount on a table
>> element;
>> * IAccessilbeTableCell::columnIndex/rowIndex return aria-col/rowlindex
>> on a cell element;
>> * IAccessilbeTableCell::columnExtent/rowExtent return aria-col/rowspan
>> on a cell element;
>> * IAccessibleTable2::cellAt returns a cell at the given row or column
>> indices which correspond to
>> IAccessilbeTableCell::columnIndex/rowIndex. If there's a gap at the
>> given indices, then null with S_FALSE is returned. If indices are out
>> of range, then it fails;
>> * If aria-col/rowspan is missed, then value of 1 is assumed;
>> * If aria-col/rowindex is missed, then index is calculated as previous
>> known index + number of cells in between.
>>
>> Thanks.
>> Alex.
>>
>> On Fri, Feb 10, 2017 at 1:34 AM, James Teh <ja...@nvaccess.org> wrote:
>> > Let's get this discussion started again. :)
>> >
>> > I was thinking about this recently and it occurred to me that we may not
>> > need new API after all, just more implementation of existing (if rarely
>> > used) API. What do you think about implementing the NAVDIR_LEFT,
>> > NAVDIR_RIGHT, NAVDIR_UP and NAVDIR_DOWN directions for accNavigate on
>> table
>> > cells? This way, we could expose the aria-col/row* values via
>> > IAccessibleTable*, even for non-contiguous indexes without any of this
>> > object attribute ugliness. Even if there were a column with cells only
>> at
>> > row 1 and row 100, a simple call to accNavigate with NAVDIR_DOWN would
>> take
>> > you straight from r1c1 to r100c1.
>> >
>> > Jamie
>> >
>> > On Wed, Jan 6, 2016 at 9:32 AM, Dominic Mazzoni <dmazz...@google.com>
>> wrote:
>> >>
>> >> I don't think it's true that tables can currently only have missing
>> cells
>> >> at the end of a row. There's nothing preventing an author from marking
>> any
>> >> cell as aria-hidden, which removes it from the accessibility tree, but
>> >> doesn't affect its row and column index. NVDA gets confused if you do

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Thank you!

On Fri, Oct 21, 2016 at 1:26 PM, Joseph Scheuhammer <cl...@alum.mit.edu>
wrote:

> Alex,
>
> I've created an issue for the core-aam to make the change [1].  I will
> bring it up at next Tue's telecon to confirm that everyone is on board,
> but based on your email, it looks like the change will be approved.
>
> Thanks.
>
> [1] https://www.w3.org/WAI/ARIA/track/issues/1051
>
> On 2016-10-21 11:37 AM, Alexander Surkov wrote:
> > Joseph, should we request an update core-aam spec to make this change?
> > anything else?
> >
> > On Thu, Oct 20, 2016 at 8:17 PM, James Teh <ja...@nvaccess.org
> > <mailto:ja...@nvaccess.org>> wrote:
> >
> >     placeholder-text is fine with me.
> >
> > On Fri, Oct 21, 2016 at 12:02 AM, Alexander Surkov
> > <surkov.alexan...@gmail.com <mailto:surkov.alexan...@gmail.com>>
> > wrote:
> >
> > Joanie suggested [1] to use 'placeholder-text' name to keep
> > IAccessible2 and ATK closer. Are there objections?
> >
> > Having, placeholder for IA2 and placeholder-text for ATK could
> > make life harder for implementators, at least it definitely
> > will do in Firefox case.
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1303429
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1303429>
> >
> > On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org
> > <mailto:ja...@nvaccess.org>> wrote:
> >
> > Visually, placeholder is certainly more like a value than
> > a name/description. However, arguably, it is semantically
> > different to a value in that it's more of a hint for the
> > user as to what to enter there. The reason for the name
> > mapping was partially because it's a nice fallback: having
> > no label at all is probably an authoring error, so it's
> > reasonable to fall back to placeholder.
> >
> > I think I originally supported the description idea, but
> > on further reflection, I'm not so sure this isn't going to
> > cause problems. It just occurred to me that if an author
> > sets title or aria-describedby, that will get mapped to
> > description, thus killing the placeholder. So, we
> > definitely need to expose the placeholder attribute.
> > However, once we have that (plus AT support), we then
> > always have to compare description with placeholder "just
> > in case", which is pretty ugly. Name is different because
> > while no name is probably authoring error, no description
> > certainly isn't.
> >
> > In short, I'd like to propose that we:
> >     1. Expose the placeholder attribute;
> > 2. Keep the current behaviour of falling back to
> > placeholder for name as a last resort;
> > 3. When 1) happens, expose explicit-name:false;
> > 4. Don't ever fall back to placeholder for description.
> >
> > Jamie
> >
> >
> > On 15/09/2016 2:38 AM, Alexander Surkov wrote:
> >> Jamie, do you have objections?
> >>
> >> On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis
> >> <ble...@vfo-group.com <mailto:ble...@vfo-group.com>> wrote:
> >>
> >> Hi,
> >>
> >> I have always thought of the placeholder more like a
> >> value for the edit field rather than a name or
> >> description.
> >>
> >> However, I think the important thing is that we have
> >> a mechanism that allows assistive technology to
> >> “know” that the place holder is present and what the
> >>     value of the placeholder is.
> >>
> >> Your suggestions accomplish that.
> >>
> >> Brett
> >>
> >>
> >>
> >>
> >>
> >> *Brett Lewis*
> >>
> >> *VFO*| Software Engineer
> >>
> >> 11800 31^st Court North, St. Petersburg, FL 33716
> >>
> >> *T*727-299-6270 
> >>
> >> ble...@vfo-group.com <mailto:ble...@vfo-group.com>
> >>
> >&

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Joseph, should we request an update core-aam spec to make this change?
anything else?

On Thu, Oct 20, 2016 at 8:17 PM, James Teh <ja...@nvaccess.org> wrote:

> placeholder-text is fine with me.
>
> On Fri, Oct 21, 2016 at 12:02 AM, Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> Joanie suggested [1] to use 'placeholder-text' name to keep IAccessible2
>> and ATK closer. Are there objections?
>>
>> Having, placeholder for IA2 and placeholder-text for ATK could make life
>> harder for implementators, at least it definitely will do in Firefox case.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1303429
>>
>> On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org> wrote:
>>
>>> Visually, placeholder is certainly more like a value than a
>>> name/description. However, arguably, it is semantically different to a
>>> value in that it's more of a hint for the user as to what to enter there.
>>> The reason for the name mapping was partially because it's a nice fallback:
>>> having no label at all is probably an authoring error, so it's reasonable
>>> to fall back to placeholder.
>>>
>>> I think I originally supported the description idea, but on further
>>> reflection, I'm not so sure this isn't going to cause problems. It just
>>> occurred to me that if an author sets title or aria-describedby, that will
>>> get mapped to description, thus killing the placeholder. So, we definitely
>>> need to expose the placeholder attribute. However, once we have that (plus
>>> AT support), we then always have to compare description with placeholder
>>> "just in case", which is pretty ugly. Name is different because while no
>>> name is probably authoring error, no description certainly isn't.
>>>
>>> In short, I'd like to propose that we:
>>> 1. Expose the placeholder attribute;
>>> 2. Keep the current behaviour of falling back to placeholder for name as
>>> a last resort;
>>> 3. When 1) happens, expose explicit-name:false;
>>> 4. Don't ever fall back to placeholder for description.
>>>
>>> Jamie
>>>
>>>
>>> On 15/09/2016 2:38 AM, Alexander Surkov wrote:
>>>
>>> Jamie, do you have objections?
>>>
>>> On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have always thought of the placeholder more like a value for the edit
>>>> field rather than a name or description.
>>>>
>>>> However, I think the important thing is that we have a mechanism that
>>>> allows assistive technology to “know” that the place holder is present and
>>>> what the value of the placeholder is.
>>>>
>>>> Your suggestions accomplish that.
>>>>
>>>> Brett
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Brett Lewis*
>>>>
>>>> *VFO* | Software Engineer
>>>>
>>>> 11800 31st Court North, St. Petersburg, FL 33716
>>>>
>>>> *T* 727-299-6270
>>>>
>>>> ble...@vfo-group.com
>>>>
>>>> www.vfo-group.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
>>>> *Sent:* Tuesday, September 13, 2016 1:52 PM
>>>> *To:* Brett Lewis <ble...@vfo-group.com>; James Teh <ja...@nvaccess.org
>>>> >
>>>> *Cc:* accessibility-...@lists.linux-foundation.org
>>>> *Subject:* Re: [Accessibility-ia2] HTML placeholder attribute
>>>>
>>>>
>>>>
>>>> Hi, Brett and all.
>>>>
>>>> There's some discrepancy in the specs between UIA and IAccessible2
>>>> mappings. UIA column states [1] that HTML placeholder is mapped to
>>>> accessible name and description, while IAccessible2 column says HTML
>>>> placeholder has same mapping as aria-placeholder. aria-placeholder is
>>>> exposed it in AriaProperties [2] for UIA and as object attribute for
>>>> IAccessible2, the generic name computation doesn't mention aria-placeholder
>>>> [3].
>>>>
>>>> Leaving aside the specs, in case of IAccessible2 Firefox does similar
>>>> things to UIA. Iirc we agreed [4] to expose placeholder as
>>>> name/description, because it requires zero adoption efforts from AT,

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Joanie suggested [1] to use 'placeholder-text' name to keep IAccessible2
and ATK closer. Are there objections?

Having, placeholder for IA2 and placeholder-text for ATK could make life
harder for implementators, at least it definitely will do in Firefox case.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1303429

On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org> wrote:

> Visually, placeholder is certainly more like a value than a
> name/description. However, arguably, it is semantically different to a
> value in that it's more of a hint for the user as to what to enter there.
> The reason for the name mapping was partially because it's a nice fallback:
> having no label at all is probably an authoring error, so it's reasonable
> to fall back to placeholder.
>
> I think I originally supported the description idea, but on further
> reflection, I'm not so sure this isn't going to cause problems. It just
> occurred to me that if an author sets title or aria-describedby, that will
> get mapped to description, thus killing the placeholder. So, we definitely
> need to expose the placeholder attribute. However, once we have that (plus
> AT support), we then always have to compare description with placeholder
> "just in case", which is pretty ugly. Name is different because while no
> name is probably authoring error, no description certainly isn't.
>
> In short, I'd like to propose that we:
> 1. Expose the placeholder attribute;
> 2. Keep the current behaviour of falling back to placeholder for name as a
> last resort;
> 3. When 1) happens, expose explicit-name:false;
> 4. Don't ever fall back to placeholder for description.
>
> Jamie
>
>
> On 15/09/2016 2:38 AM, Alexander Surkov wrote:
>
> Jamie, do you have objections?
>
> On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com>
> wrote:
>
>> Hi,
>>
>> I have always thought of the placeholder more like a value for the edit
>> field rather than a name or description.
>>
>> However, I think the important thing is that we have a mechanism that
>> allows assistive technology to “know” that the place holder is present and
>> what the value of the placeholder is.
>>
>> Your suggestions accomplish that.
>>
>> Brett
>>
>>
>>
>>
>>
>> *Brett Lewis*
>>
>> *VFO* | Software Engineer
>>
>> 11800 31st Court North, St. Petersburg, FL 33716
>>
>> *T* 727-299-6270
>>
>> ble...@vfo-group.com
>>
>> www.vfo-group.com
>>
>>
>>
>>
>>
>> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
>> *Sent:* Tuesday, September 13, 2016 1:52 PM
>> *To:* Brett Lewis <ble...@vfo-group.com>; James Teh <ja...@nvaccess.org>
>> *Cc:* accessibility-...@lists.linux-foundation.org
>> *Subject:* Re: [Accessibility-ia2] HTML placeholder attribute
>>
>>
>>
>> Hi, Brett and all.
>>
>> There's some discrepancy in the specs between UIA and IAccessible2
>> mappings. UIA column states [1] that HTML placeholder is mapped to
>> accessible name and description, while IAccessible2 column says HTML
>> placeholder has same mapping as aria-placeholder. aria-placeholder is
>> exposed it in AriaProperties [2] for UIA and as object attribute for
>> IAccessible2, the generic name computation doesn't mention aria-placeholder
>> [3].
>>
>> Leaving aside the specs, in case of IAccessible2 Firefox does similar
>> things to UIA. Iirc we agreed [4] to expose placeholder as
>> name/description, because it requires zero adoption efforts from AT, and
>> since nobody claimed they need semantics of placeholder.
>>
>> If semantics loss is crucial for you, then I think we could fix it by
>> exposing HTML placeholder this way:
>>
>> * name and description as Firefox does (fix the spec to make it clear)
>>
>> * expose placeholder object attribute
>>
>> * do not expose explicit-name='true' object attribute if placeholder was
>> used as name
>>
>>
>>
>> aria-placeholder may be left with the current mapping. How does it sound?
>>
>>
>> [1] https://w3c.github.io/aria/html-aam/html-aam.html
>> [2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
>> [3] https://w3c.github.io/aria/accname-aam/accname-aam.html
>> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817
>>
>>
>>
>> On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis <ble...@vfo-group.com>
>> wrote:
>>
>> Hi All:
>>
>> I have been looking at how the HTML placeholder attribute is supporte

[Accessibility-ia2] pre, q, ruby MSAA role mapping

[Alexander Surkov]

Hey.

What would be a correct mapping for HTML pre, q and ruby roles? I'm taking
that IA2_ROLE_TEXT_FRAME would be IA2 match for this, but I'm not clear
what MSAA match would be. Is it ROLE_SYSTEM_TEXT or ROLE_SYSTEM_GROUPING
[1]?

[1] https://rawgit.com/w3c/html-aam/master/index.html

Thanks.
Alexande.r
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] HTML5 meter element

[Alexander Surkov]

Hi.

Jason raised a concern [1] that HTML5 meter has different semantics than
HTML5 progress. HTML meter is defined [2] as

The meter 
element represents  a
scalar measurement within a known range, or a fractional value; for example
disk usage, the relevance of a query result, or the fraction of a voting
population to have selected a particular candidate.

HMTL5 progress is defined [3] as

The progress 
element represents  the
completion progress of a task. The progress is either indeterminate,
indicating that progress is being made but that it is not clear how much
more work remains to be done before the task is complete

Do we want a new role to express HTML5 meter semantics, because it's not a
progress semantically, it's rather a way to visualize scalar data of a
certain range. I'd say that HTML5 progress element is a special case
semantically of HTML5 meter.

Thanks.
Alex.

[1] https://github.com/w3c/html-aam/issues/2
[2] https://www.w3.org/TR/html5/forms.html#the-meter-element
[3] https://www.w3.org/TR/html5/forms.html#the-progress-element
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

A dummy copy/paste apparently makes a bad job. Thanks for the catch. Here
is the change [1].

I guess we could ask them to move the repo to GitHub, not sure if there are
any reasons to keep it on the LF server.

[1]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=377a994e762820a544ccd13906e0528ea8ee832f

On Sun, Sep 18, 2016 at 7:36 PM, James Teh <ja...@nvaccess.org> wrote:

> Hi Alex,
>
>
> +/** This object is a details for a target object. */
>> +const WCHAR *const IA2_RELATION_DETAILS = L"details";
>>
>
> 1. I think this is the wrong way around. "This" refers to the object we're
> pointing *from*. Target means the object we're pointing *at* (or *to*).
> Details means the object we're pointing *at* (the target) provides details
> for *this* object.
>
> 2. I think it'd be good to give a broader description here. I realise many
> of the other relations don't, but details versus describedBy needs some
> clarification and I think we should be providing more detail where possible
> anyway. Perhaps this:
>
> "The target object provides the detailed, extended description for this
> object. It provides more detailed information than would normally be
> provided using the IA2_RELATION_DESCRIBED_BY relation. A common use for
> this relation is in digital publishing where an extended description needs
> to be conveyed in a book that requires structural markup or the embedding
> of other technology to provide illustrative content."
>
> +/** The target object is a details for this object. */
>> +const WCHAR *const IA2_RELATION_DETAILS_FOR = L"detailsFor";
>>
>
> Perhaps this:
>
> "This object provides the detailed, extended description for the target
> object. See IA2_RELATION_DETAILS."
>
> +/** This object is an error for a target object. */
>> +const WCHAR *const IA2_RELATION_ERROR = L"error";
>>
>
> Again, I think these are the wrong way around. I suggest this:
>
> "The target object is the error message for this object."
>
> +/** The target object is an error for this object. */
>> +const WCHAR *const IA2_RELATION_ERROR_FOR = L"errorFor";
>>
>
> I suggest:
>
> "This object is the error message for the target object."
>
> On another note, is there any chance the Linux Foundation would let us
> develop IA2 on GitHub? Having to do code review by pasting into emails
> really sucks. Probably not worth the effort and controversy, but ... ug. :)
>
> Thanks!
>
> Jamie
>
> On 15/09/2016 4:37 AM, Alexander Surkov wrote:
>
>> Hi, Jamie.
>>
>> Here's a changeset [1] for new relations (both direct and reverse for
>> aria-details and aria-errormessage). Please review it at your earliest
>> convenience.
>>
>> Please object if you are not convinced that we have a valid use case for
>> each relation. I'll be happy to update the proposal.
>>
>> Thanks!
>> Alex.
>>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Fine with me.

On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org> wrote:

> Visually, placeholder is certainly more like a value than a
> name/description. However, arguably, it is semantically different to a
> value in that it's more of a hint for the user as to what to enter there.
> The reason for the name mapping was partially because it's a nice fallback:
> having no label at all is probably an authoring error, so it's reasonable
> to fall back to placeholder.
>
> I think I originally supported the description idea, but on further
> reflection, I'm not so sure this isn't going to cause problems. It just
> occurred to me that if an author sets title or aria-describedby, that will
> get mapped to description, thus killing the placeholder. So, we definitely
> need to expose the placeholder attribute. However, once we have that (plus
> AT support), we then always have to compare description with placeholder
> "just in case", which is pretty ugly. Name is different because while no
> name is probably authoring error, no description certainly isn't.
>
> In short, I'd like to propose that we:
> 1. Expose the placeholder attribute;
> 2. Keep the current behaviour of falling back to placeholder for name as a
> last resort;
> 3. When 1) happens, expose explicit-name:false;
> 4. Don't ever fall back to placeholder for description.
>
> Jamie
>
>
> On 15/09/2016 2:38 AM, Alexander Surkov wrote:
>
> Jamie, do you have objections?
>
> On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com>
> wrote:
>
>> Hi,
>>
>> I have always thought of the placeholder more like a value for the edit
>> field rather than a name or description.
>>
>> However, I think the important thing is that we have a mechanism that
>> allows assistive technology to “know” that the place holder is present and
>> what the value of the placeholder is.
>>
>> Your suggestions accomplish that.
>>
>> Brett
>>
>>
>>
>>
>>
>> *Brett Lewis*
>>
>> *VFO* | Software Engineer
>>
>> 11800 31st Court North, St. Petersburg, FL 33716
>>
>> *T* 727-299-6270
>>
>> ble...@vfo-group.com
>>
>> www.vfo-group.com
>>
>>
>>
>>
>>
>> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
>> *Sent:* Tuesday, September 13, 2016 1:52 PM
>> *To:* Brett Lewis <ble...@vfo-group.com>; James Teh <ja...@nvaccess.org>
>> *Cc:* accessibility-...@lists.linux-foundation.org
>> *Subject:* Re: [Accessibility-ia2] HTML placeholder attribute
>>
>>
>>
>> Hi, Brett and all.
>>
>> There's some discrepancy in the specs between UIA and IAccessible2
>> mappings. UIA column states [1] that HTML placeholder is mapped to
>> accessible name and description, while IAccessible2 column says HTML
>> placeholder has same mapping as aria-placeholder. aria-placeholder is
>> exposed it in AriaProperties [2] for UIA and as object attribute for
>> IAccessible2, the generic name computation doesn't mention aria-placeholder
>> [3].
>>
>> Leaving aside the specs, in case of IAccessible2 Firefox does similar
>> things to UIA. Iirc we agreed [4] to expose placeholder as
>> name/description, because it requires zero adoption efforts from AT, and
>> since nobody claimed they need semantics of placeholder.
>>
>> If semantics loss is crucial for you, then I think we could fix it by
>> exposing HTML placeholder this way:
>>
>> * name and description as Firefox does (fix the spec to make it clear)
>>
>> * expose placeholder object attribute
>>
>> * do not expose explicit-name='true' object attribute if placeholder was
>> used as name
>>
>>
>>
>> aria-placeholder may be left with the current mapping. How does it sound?
>>
>>
>> [1] https://w3c.github.io/aria/html-aam/html-aam.html
>> [2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
>> [3] https://w3c.github.io/aria/accname-aam/accname-aam.html
>> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817
>>
>>
>>
>> On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis <ble...@vfo-group.com>
>> wrote:
>>
>> Hi All:
>>
>> I have been looking at how the HTML placeholder attribute is supported by
>> IA2.
>>
>> According to the HTML accessibility API mappings at:
>> https://www.w3.org/TR/html-aam-1.0/
>>
>> The placeholder in HTML should be handled just like the
>> aria-placeholder.
>>
>> According to the core api accessibility mappings
>> http://

Re: [Accessibility-ia2] Fwd: figure role backgrounds

[Alexander Surkov]

Hi, Rich.


On Wed, Sep 14, 2016 at 4:56 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:

> Alex,
>
> 1. Figure is not just semantic as you expect  to go with it
> and there is no desire for that in SVG
>

I wish to have more details on this, because as I see it  is
just a label for  and the authors may or may not use it if they
want.



>
> 2. If you look at the SVG2 spec. they list all the elements they want in
> it (including . They have chosen to NOT have it in the
> specification and it is in lock down.
>

I didn't suggested to extend SVG, right?

Among other things SVG2 says: "SVG 2 Requirement. Resolution: Allow audio,
canvas, iframe and video elements from HTML5, don't introduce almost the
same but slightly different SVG NS elements. Purpose: To allow various HTML
embedded content elements to be used directly in SVG and support dynamic
loading of content." [1]. It looks like HTML figure can be re-used in SVG,
according to this requirement.


>
> 3. If you recall from the first ARIA 1.1 meeting we had in Toronto (at
> Mozilla) the intent was to reproduce HTML semantics in ARIA as they are
> needed. This is in large part to ensure that HTML elements can be defined
> in terms of ARIA semantics so that they can be mapped to those semantics.
>

I'm good to extend ARIA as long as it's needed, but still I need to
understand a use case for each new feature.


>
> 4. Given that HTML has a LOT of elements, we are picking those that can be
> easily mapped and for which there is an inherent need first. The Web
> Platform people want semantics for all HTML elements in ARIA as they want
> to get away from using HTML and create their own DOM. So I expect roles for
> virtually all HTML elements (including block quotes).
>

Are there any links on public discussions where I can learn more about the
web platform initiatives and why they need semantics for all HTML elements
in ARIA, or could you cc someone, who will kindly outline their ideas on
this list, please?


>
> Steve Faulkner asked for a Figure role and we needed one for SVG (Amelia's
> email). So, we created a role for it.
>

Steve, could you please put your thinking here about figure role?


>
> There are a lot of features in ARIA 1.1 that people need to have us get
> out into browsers and we had a limited timeline for ARIA 1.1. It is for
> these reasons that we cut the features off putting all HTML roles into ARIA
> 1.1.
>
> If you would like to participate in setting the bar lower or higher you
> should participate more when we start ARIA 2.0. I believe you were at that
> first meeting at Mozilla when we kicked off ARIA 1.1 work.
>

fair enough, but still I've got more involved at implementation stage,
because I'd need to understand each feature I add into Gecko.

[1] https://www.w3.org/TR/SVG2/embedded.html



>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
> To: Rich Schwerdtfeger <richsch...@gmail.com>
> Cc: IA2 List <accessibility-...@lists.linux-foundation.org>, Alexander
> Surkov <asur...@mozilla.com>
> Subject: Re: [Accessibility-ia2] Fwd: figure role backgrounds
> Date: Wed, Sep 14, 2016 3:17 PM
>
> Hi, Rich. There are still concerns left. Here's my email [1].
> Alex.
>
> [1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0051.html
>
> On Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger <richsch...@gmail.com
> > wrote:
>
> Alex,
>
> Are you satisfied with Amelia’s more detailed response and why it is
> needed in SVG? Figures are used a lot in SVG drawings.
>
> If so, I would like your approval on the figure mapping. I am trying hard
> to get ARIA 1.1 wrapped up so that we can focus efforts on helping you and
> others on the JavaScript Accessibility API work and other work around ARIA
> 2.0. I just had a meeting with a product team and they are screaming with a
> lot of the changes that are going into ARIA 1.1: feeds, aria-haspopup value
> changes that include dialog and tree and much more.
>
> Rich
>
> Rich Schwerdtfeger
>
>
>
>
>
> Begin forwarded message:
>
> *From: *Amelia Bellamy-Royds <amelia.bellamy.ro...@gmail.com>
> *Subject: **Re: figure role backgrounds*
> *Date: *September 12, 2016 at 11:55:09 PM CDT
> *To: *Alexander Surkov <surkov.alexan...@gmail.com>
> *Cc: *ARIA Working Group <public-a...@w3.org>, SVG-A11y TF <
> public-svg-a...@w3.org>, Richard Schwerdtfeger <richsch...@gmail.com>
>
> Hi Alexander,
>
> A little more detail on what Richard said…
>
> The figure role came from the SVG Accessibility task force, when

Re: [Accessibility-ia2] Fwd: figure role backgrounds

[Alexander Surkov]

Hi, Rich. There are still concerns left. Here's my email [1].
Alex.

[1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0051.html


On Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger <richsch...@gmail.com>
wrote:

> Alex,
>
> Are you satisfied with Amelia’s more detailed response and why it is
> needed in SVG? Figures are used a lot in SVG drawings.
>
> If so, I would like your approval on the figure mapping. I am trying hard
> to get ARIA 1.1 wrapped up so that we can focus efforts on helping you and
> others on the JavaScript Accessibility API work and other work around ARIA
> 2.0. I just had a meeting with a product team and they are screaming with a
> lot of the changes that are going into ARIA 1.1: feeds, aria-haspopup value
> changes that include dialog and tree and much more.
>
> Rich
>
> Rich Schwerdtfeger
>
>
>
>
> Begin forwarded message:
>
> *From: *Amelia Bellamy-Royds <amelia.bellamy.ro...@gmail.com>
> *Subject: **Re: figure role backgrounds*
> *Date: *September 12, 2016 at 11:55:09 PM CDT
> *To: *Alexander Surkov <surkov.alexan...@gmail.com>
> *Cc: *ARIA Working Group <public-a...@w3.org>, SVG-A11y TF <
> public-svg-a...@w3.org>, Richard Schwerdtfeger <richsch...@gmail.com>
>
> Hi Alexander,
>
> A little more detail on what Richard said…
>
> The figure role came from the SVG Accessibility task force, when we were
> trying to identify the "missing roles" for describing graphics in web
> pages.  The fact that  already existed in HTML was seen as a reason
> *for*, rather than a reason against, adding a corresponding role to
> ARIA.  We wanted non-HTML documents to also be able to expose those
> semantics.
>
> ARIA is not merely an extension to HTML.  ARIA is (supposed to be) a
> complete language for describing the semantics of internet applications and
> web documents.  Although limitations of HTML, relative to native
> applications, were a driving force for the original creation of ARIA, that
> shouldn't be the end of it.
>
> ARIA is available to be used in any XML syntax, including SVG and ePub.
> Ideally, other XML formats (such as those used for office documents) would
> also adopt ARIA mappings, so that software could leverage the existing role
> mappings, and assistive tech could give users a consistent experience,
> whether they are viewing content in a web browser or in a native
> application.
>
> We're a long way from that still.  There are many semantic features of
> HTML which have defined mappings in the operating system accessibility APIs
> but which can't be described yet in ARIA.  (For examples, just look at all
> the custom mappings in the HTML-AAM
> <http://w3c.github.io/aria/html-aam/html-aam.html#html-element-role-mappings>.)
>  And that doesn't even cover all the semantic nuances described in the HTML
> specs for which the accessibility APIs don't have equivalents, including
> such important distinctions as , , and .  I would very much
> like to see ARIA equivalents for *every* HTML semantic element in ARIA 2,
> and I know that's a planned topic of discussion for web components / custom
> elements accessibility.
>
> Going back to the specifics of the figure role, and why we thought it was
> important:
>
> Figures, and figure-like objects such as tables and equations, are often
> referenced by name and number.  In both print and web layouts, their
> position in the display may be constrained by practical considerations, so
> that they aren't immediately adjacent to the relevant prose.   Ideally on
> the web, any references to a figure or table would include a cross-link,
> but that doesn't always happen when content originally made for print gets
> adapted for the web.  Even if it does happen, a link on its own doesn't
> make it easy for non-visual users to skim through and find the figures.
>
> Some screen readers offer users a way to jump to images, just like they
> jump to links or headings. But that is currently imperfect, since there may
> be lots of minor images (e.g., icons) on the page, and since some figures
> may not be graphics (e.g., math equations, code samples), or may be
> graphics marked up in a way that doesn't get recognized as role=img (e.g.,
> inline SVG, video, flash objects).
>
> The figure role therefore:
>
>- indicates that the region is a self-contained figure including its
>captions, and software may safely re-position it out of the flow of the
>text (but, unlike a complementary region, it is still an essential part of
>the main text or article, and wouldn't normally be omitted or published
>separately)
>
>- indicates that users would benefit from a way of easily finding this
>

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Jamie, do you have objections?

On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com> wrote:

> Hi,
>
> I have always thought of the placeholder more like a value for the edit
> field rather than a name or description.
>
> However, I think the important thing is that we have a mechanism that
> allows assistive technology to “know” that the place holder is present and
> what the value of the placeholder is.
>
> Your suggestions accomplish that.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Tuesday, September 13, 2016 1:52 PM
> *To:* Brett Lewis <ble...@vfo-group.com>; James Teh <ja...@nvaccess.org>
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Re: [Accessibility-ia2] HTML placeholder attribute
>
>
>
> Hi, Brett and all.
>
> There's some discrepancy in the specs between UIA and IAccessible2
> mappings. UIA column states [1] that HTML placeholder is mapped to
> accessible name and description, while IAccessible2 column says HTML
> placeholder has same mapping as aria-placeholder. aria-placeholder is
> exposed it in AriaProperties [2] for UIA and as object attribute for
> IAccessible2, the generic name computation doesn't mention aria-placeholder
> [3].
>
> Leaving aside the specs, in case of IAccessible2 Firefox does similar
> things to UIA. Iirc we agreed [4] to expose placeholder as
> name/description, because it requires zero adoption efforts from AT, and
> since nobody claimed they need semantics of placeholder.
>
> If semantics loss is crucial for you, then I think we could fix it by
> exposing HTML placeholder this way:
>
> * name and description as Firefox does (fix the spec to make it clear)
>
> * expose placeholder object attribute
>
> * do not expose explicit-name='true' object attribute if placeholder was
> used as name
>
>
>
> aria-placeholder may be left with the current mapping. How does it sound?
>
>
> [1] https://w3c.github.io/aria/html-aam/html-aam.html
> [2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
> [3] https://w3c.github.io/aria/accname-aam/accname-aam.html
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817
>
>
>
> On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis <ble...@vfo-group.com> wrote:
>
> Hi All:
>
> I have been looking at how the HTML placeholder attribute is supported by
> IA2.
>
> According to the HTML accessibility API mappings at:
> https://www.w3.org/TR/html-aam-1.0/
>
> The placeholder in HTML should be handled just like the aria-placeholder.
>
> According to the core api accessibility mappings
> http://w3c.github.io/aria/core-aam/core-aam.html
>
> The aria-placeholder is mapped to an Ia2 object attribute of placeholder.
>
> So, it sounds like the HTML placeholder should be mapped to an IA2 object
> attribute of placeholder.
>
> Currently Firefox seems to support the placeholder as the name of the
> field if there is no other name provided by the page author (from
> https://bugzilla.mozilla.org/show_bug.cgi?id=545817.
>
> This seems to contradict the description of aria-placeholder from
>
> the WAI-ARIA) 1.1 spec at http://rawgit.com/w3c/aria/
> master/aria/aria.html#aria-placeholder
>
> Says:
>
>
>
> “[ARIA 1.1] Defines a short hint (a word or short phrase) intended to aid
> the user with data entry when the control has no value. A hint could be a
> sample value or a brief description of the expected format.
>
>
>
> Authors should not use aria-placeholder
>
> instead of a label as their purposes are different: The label indicates
> what kind of information is expected. The placeholder text is a hint about
> the
>
> expected value. See related aria-labelledby and aria-label.
>
>
>
> Authors should present this hint to the user by displaying the hint text
> at any time the control's value is the empty string. This includes cases
> where
>
> the control first receives focus, and when users remove a
> previously-entered value.
>
>
>
> NOTE
>
>
>
> As is the case with the related HTML placeholder
>
> attribute, use of placeholder text as a replacement for a displayed label
> can reduce the accessibility and usability of the control for a range of
> users
>
> including older users and users with cognitive, mobility, fine motor skill
> or vision impairments. While the hint given by the control's label is shown
>
> at all times, the sh

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Hi, Brett and all.

There's some discrepancy in the specs between UIA and IAccessible2
mappings. UIA column states [1] that HTML placeholder is mapped to
accessible name and description, while IAccessible2 column says HTML
placeholder has same mapping as aria-placeholder. aria-placeholder is
exposed it in AriaProperties [2] for UIA and as object attribute for
IAccessible2, the generic name computation doesn't mention aria-placeholder
[3].

Leaving aside the specs, in case of IAccessible2 Firefox does similar
things to UIA. Iirc we agreed [4] to expose placeholder as
name/description, because it requires zero adoption efforts from AT, and
since nobody claimed they need semantics of placeholder.

If semantics loss is crucial for you, then I think we could fix it by
exposing HTML placeholder this way:
* name and description as Firefox does (fix the spec to make it clear)
* expose placeholder object attribute
* do not expose explicit-name='true' object attribute if placeholder was
used as name

aria-placeholder may be left with the current mapping. How does it sound?

[1] https://w3c.github.io/aria/html-aam/html-aam.html
[2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
[3] https://w3c.github.io/aria/accname-aam/accname-aam.html
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817


On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis  wrote:

> Hi All:
>
> I have been looking at how the HTML placeholder attribute is supported by
> IA2.
>
> According to the HTML accessibility API mappings at:
> https://www.w3.org/TR/html-aam-1.0/
>
> The placeholder in HTML should be handled just like the aria-placeholder.
>
> According to the core api accessibility mappings
> http://w3c.github.io/aria/core-aam/core-aam.html
>
> The aria-placeholder is mapped to an Ia2 object attribute of placeholder.
>
> So, it sounds like the HTML placeholder should be mapped to an IA2 object
> attribute of placeholder.
>
> Currently Firefox seems to support the placeholder as the name of the
> field if there is no other name provided by the page author (from
> https://bugzilla.mozilla.org/show_bug.cgi?id=545817.
>
> This seems to contradict the description of aria-placeholder from
>
> the WAI-ARIA) 1.1 spec at http://rawgit.com/w3c/aria/
> master/aria/aria.html#aria-placeholder
>
> Says:
>
>
>
> “[ARIA 1.1] Defines a short hint (a word or short phrase) intended to aid
> the user with data entry when the control has no value. A hint could be a
> sample value or a brief description of the expected format.
>
>
>
> Authors should not use aria-placeholder
>
> instead of a label as their purposes are different: The label indicates
> what kind of information is expected. The placeholder text is a hint about
> the
>
> expected value. See related aria-labelledby and aria-label.
>
>
>
> Authors should present this hint to the user by displaying the hint text
> at any time the control's value is the empty string. This includes cases
> where
>
> the control first receives focus, and when users remove a
> previously-entered value.
>
>
>
> NOTE
>
>
>
> As is the case with the related HTML placeholder
>
> attribute, use of placeholder text as a replacement for a displayed label
> can reduce the accessibility and usability of the control for a range of
> users
>
> including older users and users with cognitive, mobility, fine motor skill
> or vision impairments. While the hint given by the control's label is shown
>
> at all times, the short hint given in the placeholder attribute is only
> shown before the user enters a value. Furthermore, placeholder text may be
> mistaken for a pre-filled value, and as commonly implemented the default
> color of the placeholder text provides insufficient contrast and the lack
> of a separate visible label reduces the size of the hit region available
> for setting focus on the control.”
>
>
>
>
>
> I am suggesting that we all agree to present the HTML placeholder just
> like the aria-placeholder using the IA2 object attribute of placeholder?
>
> This provides the most flexibility for screenreaders to present the
> placeholder information anyway they see fit.  Using the placeholder as the
> name is not as flexible as the screenreader cannot distinguish between the
> placeholder and the label in this case.
>
> What does everyone think?
>
> Thanks,
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 IDL

[Alexander Surkov]

Hi, Rich.

I didn't updated yet IDL for details and errormessage. I wanted to make it
on this week, hoping we can sort out with a reverse relation for
aria-details [1].

Here' a IDL repo [2].

Thanks.
Alex.

[1]
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-September/002145.html
[2] http://git.linuxfoundation.org/?p=a11y/ia2.git;a=summary

On Mon, Sep 12, 2016 at 12:23 PM, Rich Schwerdtfeger 
wrote:

> Alex,
>
> Would you please email me the updated IDL for IA2.
>
> I need to have the definitions for the error and details relationships as
> well as the reverse relationship for the error relationship.
>
> I also need the new IA2 role for the Landmark role.
>
> If you are not able to do it, please send it to me and I will be happy to
> update it.
>
> Thanks,
>
> Rich
>
> Rich Schwerdtfeger
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[Alexander Surkov]

On Thu, Sep 8, 2016 at 8:58 AM, James Teh <ja...@nvaccess.org> wrote:

> He's talking about having a concatenated version of errormessage (i.e. all
> the error message text in one call), not concatenating it to description.
> That's why he asked, "Would it be helpful if we had 'errormessage' object
> attribute for that?" Description and describedBy were never mentioned.
>
thank you, Jamie.


> That said, while having this as an object attribute would work, having a
> potentially long message in an object attribute seems nasty to me.
>

ok, I'm good with either case. On the other hand it's probably a good
reason to implement 'attribute' method [1]

[1]
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible2__2.html


>
> On 8/09/2016 10:54 PM, Richard Schwerdtfeger wrote:
>
> Alex, you must not NOT concatenate error message to details or describedby
> relationships. You were given a 5 reasons why this would be a huge problem.
>
> Also aria-errormessage does not take multiple IDs.
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> <surkov.alexan...@gmail.com>
> To: James Teh <ja...@nvaccess.org> <ja...@nvaccess.org>
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list
> <accessibility-...@lists.linux-foundation.org>
> <accessibility-...@lists.linux-foundation.org>, Brett Lewis
> <ble...@freedomscientific.com> <ble...@freedomscientific.com>, Joanmarie
> Diggs <jdi...@igalia.com> <jdi...@igalia.com>, Dominic Mazzoni
> <dmazz...@google.com> <dmazz...@google.com>
> Subject: Re: Agreement on concatenation of aria-describedby and
> aria-errormessage relationships
> Date: Thu, Sep 8, 2016 6:41 AM
>
> Understood. Would it be helpful if we had 'errormessage' object attribute
> for that? I assume that having both a relation and a concatenated string
> for error message would address needs of all consumers.
>
> On Wed, Sep 7, 2016 at 8:16 PM, James Teh <ja...@nvaccess.org> wrote:
>
> To clarify, I'm concerned about aria-errormessage here. For aria-details,
> we wouldn't be trying to report the information as one chunk. Instead, the
> user would perform a command to navigate to the details, at which point
> they would browse it like they browse any other content.
>
>
>
> For aria-errormessage, the use case I'm concerned about is when the user
> focuses an aria-invalid element with aria-errormessage. In that case, we
> need to report the aria-errormessage content as one chunk. Because this is
> focus handling, we don't use the buffer for this. There may not even be a
> buffer in this case, since we don't need a buffer in, say, an ARIA
> role="application".
>
> Jamie
>
> On 8/09/2016 2:15 AM, Alexander Surkov wrote:
>
> Shouldn't it be same speed as walking the virtual buffer? I assume
> aria-details may contain complex content, for example Pythagorean Theorem
> from [1], that may be not suitable for stringification in general.
>
>
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
>
> On Tue, Sep 6, 2016 at 11:31 PM, James Teh <ja...@nvaccess.org> wrote:
>
> That doesn't solve the need to walk the tree to gather the error message,
> which is the real problem.
>
> On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:
>
> I think Dominic's suggestion on an interface tester with bit flags works
> well.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh <ja...@nvaccess.org> <ja...@nvaccess.org>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com,
> ble...@freedomscientific.com, jdi...@igalia.com
> Cc: accessibility-...@lists.linux-foundation.org
> Subject: Re: Agreement on concatenation of aria-describedby and
> aria-errormessage relationships
> Date: Tue, Sep 6, 2016 7:19 PM
>
>
> Fair enough. Thanks for the clear reasoning.
>
>
>
> My one remaining concern is performance, but we will clearly need to find
> an alternative technical solution to this problem. In short, not
> concatenating means that for every focus event, we need to check for the
> invalid state plus an errormessage relation and then, if one is found, walk
> the tree for the target to gather the message. The latter in particular
> could be unacceptably slow.
>
> On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:
>
>
> The ARIA working group is against concatenating the description and
> relationship strings. I will try to summarize:
>
> Specifically, concatenation by browsers could:
>
>
>1. Defeat the purp

Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[Alexander Surkov]

Understood. Would it be helpful if we had 'errormessage' object attribute
for that? I assume that having both a relation and a concatenated string
for error message would address needs of all consumers.

On Wed, Sep 7, 2016 at 8:16 PM, James Teh <ja...@nvaccess.org> wrote:

> To clarify, I'm concerned about aria-errormessage here. For aria-details,
> we wouldn't be trying to report the information as one chunk. Instead, the
> user would perform a command to navigate to the details, at which point
> they would browse it like they browse any other content.
>
>
> For aria-errormessage, the use case I'm concerned about is when the user
> focuses an aria-invalid element with aria-errormessage. In that case, we
> need to report the aria-errormessage content as one chunk. Because this is
> focus handling, we don't use the buffer for this. There may not even be a
> buffer in this case, since we don't need a buffer in, say, an ARIA
> role="application".
>
> Jamie
>
>
> On 8/09/2016 2:15 AM, Alexander Surkov wrote:
>
> Shouldn't it be same speed as walking the virtual buffer? I assume
> aria-details may contain complex content, for example Pythagorean Theorem
> from [1], that may be not suitable for stringification in general.
>
>
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
>
> On Tue, Sep 6, 2016 at 11:31 PM, James Teh <ja...@nvaccess.org> wrote:
>
>> That doesn't solve the need to walk the tree to gather the error message,
>> which is the real problem.
>>
>> On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:
>>
>> I think Dominic's suggestion on an interface tester with bit flags works
>> well.
>>
>> Rich
>>
>>
>>
>> Rich Schwerdtfeger
>>
>>
>>
>> - Original message -
>> From: James Teh <ja...@nvaccess.org> <ja...@nvaccess.org>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com,
>> ble...@freedomscientific.com, jdi...@igalia.com
>> Cc: accessibility-...@lists.linux-foundation.org
>> Subject: Re: Agreement on concatenation of aria-describedby and
>> aria-errormessage relationships
>> Date: Tue, Sep 6, 2016 7:19 PM
>>
>>
>> Fair enough. Thanks for the clear reasoning.
>>
>>
>>
>> My one remaining concern is performance, but we will clearly need to find
>> an alternative technical solution to this problem. In short, not
>> concatenating means that for every focus event, we need to check for the
>> invalid state plus an errormessage relation and then, if one is found, walk
>> the tree for the target to gather the message. The latter in particular
>> could be unacceptably slow.
>>
>> On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:
>>
>>
>> The ARIA working group is against concatenating the description and
>> relationship strings. I will try to summarize:
>>
>> Specifically, concatenation by browsers could:
>>
>>
>>1. Defeat the purposes of aria-errormessage. The aria-errormessage
>>relationship is designed to ensure assistive technology users are as aware
>>of error messages as other users and to enable them to distinguish between
>>error messages and field descriptions. The constraints of ARIA 1.0, and
>>every other accessibility standard and API that preceded it, have forced
>>developers to blend error messages and field descriptions. This blending
>>has long inhibited both the perception and understanding of error 
>> messages,
>>which are critical to effective operation of many user interfaces.
>>2. increase cognitive load for users when errors are present.
>>Especially for screen reader users, we already have severe challenges with
>>excess verbosity that forces the user to expend energy sorting out the 
>> most
>>important aspects of screen reader feedback. Concatenating potentially 
>> very
>>disparate content in this manner would aggravate the verbosity problem.
>>3. Reduce assistive technology flexibility. Part of the power of ARIA
>>is that it gives assistive technologies the ability to present content in
>>the manner best suited for their target audiences. When browsers eliminate
>>semantically relevant distinctions, this type of flexibility is 
>> diminished.
>>If this concatenation were performed, it would essentially eliminate the
>>semantic distinctions.  If an assistive technology developer wanted to
>>present the field description separate from the error messages, the
>>developer would be forced to ignore the browser-computed descrip

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

On Wed, Sep 7, 2016 at 3:25 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:

> Hi Alex,
>
> Correct, aria-details requires no special role. However, the use case is
> for the digital publishing industry. They want to be able to take a piece
> of content and go to the alternative content that provides detailed
> information which could be alternative content as we discussed previously.
> The user may or may not wish to go back to the content the details is being
> provided for.
>

I'm not that confident, but if a screen reader performs the navigation,
then it can track the state, so that if the screen reader moved the user
somewhere, then it should be able to move it back without browser support.
Having said that, I'm not necessary argue against aria-details reverse
relation, but I would like to have a use case, where a screen reader would
be forced to traverse the whole document if it hadn't a reverse relation.


>
> The need for a reverse relationship for the error message is more critical.
>
> So, do we agree on a reverse relationship for error message and not
> details?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> To: Brett Lewis <ble...@vfo-group.com>
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org" <
> ja...@nvaccess.org>, "jdi...@igalia.com" <jdi...@igalia.com>, "
> accessibility-...@lists.linux-foundation.org" <Accessibility-ia2@lists.
> linux-foundation.org>
> Subject: Re: Reverse relationships
> Date: Wed, Sep 7, 2016 10:34 AM
>
> You're right. An element referred by aria-errormessage can be an alert of
> live region and thus should be announced by a screen reader, when it pops
> up. In this case, it seems the screen reader may need to find a context
> element, and if this is true, then the reverse relation is needed.
>
> aria-details are different, since they are more like labels and
> descriptions, and I guess thus they should be skipped when navigating the
> virtual buffer. That suggests that aria-details either needs a role (or
> xml-roles object attribute) or a reverse relation.
>
> On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis <ble...@vfo-group.com>
> wrote:
>
> Hi,
>
> Is that documented somewhere?
>
> I read through the information on error and I don’t see anything about AT
> skipping error messages if encountering them while reading through the
> virtual buffer.
>
> Have I misunderstood something?
>
> Thanks,
>
> Brett
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 8:02 AM
> *To:* Brett Lewis <ble...@vfo-group.com>
> *Cc:* Richard Schwerdtfeger <sch...@us.ibm.com>; ja...@nvaccess.org;
> jdi...@igalia.com; accessibility-...@lists.linux-foundation.org
> *Subject:* Re: Reverse relationships
>
>
>
> Hi, Brett.
>
> Can you please elaborate your use case? My understanding is AT skips
> error/details, if the user encounters them, but announce them, when the
> user navigates to an element related with error/details. Why would AT need
> to find a related element by error/details?
>
> Thanks.
>
> Alex.
>
>
>
> On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis <ble...@vfo-group.com> wrote:
>
> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <
> ble...@vfo-group.com>; jdi...@igalia.com
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Reverse relationships
>
>
>
> We need agreement:
>
>
>
> Should the error message and details relationships have reverse mappings?
>
>
>
> Rich
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

Thank you, Jamie. I'm taking that screen readers may need to a context
element, when error message pops up, as a use case for a reverse relation
(if not, please correct me).

Could you also comment my guess about aria-details? If a screen reader
skips aria-details elements when navigating, then what mechanism we'd use
for aria-details element detection.

On Wed, Sep 7, 2016 at 8:12 PM, James Teh <ja...@nvaccess.org> wrote:

> Agreed. Happy to have a reverse relation for errormessage, since we seem
> to have a use case. We don't seem to have a compelling use case for a
> reverse relation for details, so let's leave it out for now.
>
> On 8/09/2016 5:25 AM, Richard Schwerdtfeger wrote:
>
> Hi Alex,
>
> Correct, aria-details requires no special role. However, the use case is
> for the digital publishing industry. They want to be able to take a piece
> of content and go to the alternative content that provides detailed
> information which could be alternative content as we discussed previously.
> The user may or may not wish to go back to the content the details is being
> provided for.
>
> The need for a reverse relationship for the error message is more critical.
>
> So, do we agree on a reverse relationship for error message and not
> details?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> <surkov.alexan...@gmail.com>
> To: Brett Lewis <ble...@vfo-group.com> <ble...@vfo-group.com>
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org"
> <ja...@nvaccess.org> <ja...@nvaccess.org> <ja...@nvaccess.org>,
> "jdi...@igalia.com" <jdi...@igalia.com> <jdi...@igalia.com>
> <jdi...@igalia.com>, "accessibility-...@lists.linux-foundation.org"
> <accessibility-...@lists.linux-foundation.org> <Accessibility-ia2@lists.
> linux-foundation.org> <accessibility-...@lists.linux-foundation.org>
> Subject: Re: Reverse relationships
> Date: Wed, Sep 7, 2016 10:34 AM
>
> You're right. An element referred by aria-errormessage can be an alert of
> live region and thus should be announced by a screen reader, when it pops
> up. In this case, it seems the screen reader may need to find a context
> element, and if this is true, then the reverse relation is needed.
>
> aria-details are different, since they are more like labels and
> descriptions, and I guess thus they should be skipped when navigating the
> virtual buffer. That suggests that aria-details either needs a role (or
> xml-roles object attribute) or a reverse relation.
>
> On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis <ble...@vfo-group.com>
> wrote:
>
> Hi,
>
> Is that documented somewhere?
>
> I read through the information on error and I don’t see anything about AT
> skipping error messages if encountering them while reading through the
> virtual buffer.
>
> Have I misunderstood something?
>
> Thanks,
>
> Brett
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 8:02 AM
> *To:* Brett Lewis <ble...@vfo-group.com>
> *Cc:* Richard Schwerdtfeger <sch...@us.ibm.com>; ja...@nvaccess.org;
> jdi...@igalia.com; accessibility-...@lists.linux-foundation.org
> *Subject:* Re: Reverse relationships
>
>
>
> Hi, Brett.
>
> Can you please elaborate your use case? My understanding is AT skips
> error/details, if the user encounters them, but announce them, when the
> user navigates to an element related with error/details. Why would AT need
> to find a related element by error/details?
>
> Thanks.
>
> Alex.
>
>
>
> On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis <ble...@vfo-group.com> wrote:
>
> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Le

Re: [Accessibility-ia2] Bitmask for rare accessibility attributes

[Alexander Surkov]

I'd say the bitmask idea is covered by states concept, for example, see
STATE_SYSTEM_HASPOPUP [1]. I guess we can add more IA2 states if needed.

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373609(v=vs.85).aspx

On Tue, Sep 6, 2016 at 8:39 PM, James Teh  wrote:

> That's a very interesting idea.
>
>
> Note that for errormessage, we can first test for the invalid state, so
> this wouldn't help that. (The bigger problem there is walking the tree to
> get the message from the target.)
>
> What do you think about using an object attribute (or attributes) to do
> this, rather than a separate bit mask? That way, it's much easier to add
> new ones. Also, I'm guessing most AT (certainly screen readers) already
> have to fetch attributes anyway, so this avoids an extra call.
>
> Thanks!
>
> Jamie
>
>
> On 7/09/2016 8:42 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
>
> One of the objections Jamie brought up to making aria-errormessage an
> additional interface is that it increases the number of interfaces AT needs
> to call on every single accessible. I've also thought about this same
> issue, as the number of nodes in an average web page continues to grow
> along with the number of interfaces in IA2.
>
> What would folks think of adding some sort of bitmask to allow AT to
> quickly test for the presence of lots of properties at the same time?
> Something like:
>
> HRESULT propertyBitmask([out, retval] IA2PropertyBitmask *bitmask)
>
> enum   IA2PropertyBitmask {
>   IA2_HAS_NAME = 0x01,
>   IA2_HAS_DESCRIPTION = 0x02,
>   IA2_HAS_ERRORMESSAGE = 0x04,
>   ...
> }
>
> One could imagine variants of this, for example AT could fill in the
> bitmask with properties it's interested in, and the browser would only have
> to compute those.
>
> - Dominic
>
>
>
> ___
> Accessibility-ia2 mailing 
> listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Form role mapping

[Alexander Surkov]

There's a point in discussing, the spec can be changed, if there's solid
ground for that.

My concerns are:

* Both IA2 and ATK have a better role match for both role='form' and HTML
form, which is ATK_ROLE_FORM and IA2_ROLE_FORM. Thus if there's no strong
reason why we have to use a 'weaker' role, then I'd say we should go with
the match.

* AT and browsers support those roles, if Firefox Nightly starts to expose
IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it breaks all existing screen
reader versions. In case of commercial screen readers this is painful for
the users, since they have to buy a new version of their screen reader.

* I'm not certain if changing IA2_ROLE_FORM to IA2_ROLE_LANDMARK adds any
benefits for screen readers. I'd be curious to hear about them.

On Tue, Sep 6, 2016 at 7:15 PM, James Teh  wrote:

> Hi Rich,
>
>
> I've already stated my view on this:
>
>
> I understand the reason for the use of the landmark role for role="form".
> However, I disagree with the HTML form element being mapped to the landmark
> role because semantics are lost. The fact that something is a form has more
> semantic value than just being a landmark. Still, if the spec already
> requires this, I guess we have little choice but to comply at this stage.
>
>
>
> At the end of the day, I'm not sure why this is still an open question,
> since it seems that the spec groups have already made a decision on this:
>
> The HTML the form element now uses the ARIA mappings for the form role.
> See "Use WAI-ARIA mapping” under the form element. This is for all
> platforms.
>
>
> In other words, we can't comply with the spec unless we do as you suggest,
> so there is no other choice. There is no point in discussing this further.
>
> Thanks,
> Jamie
>
>
> On 7/09/2016 5:54 AM, Richard Schwerdtfeger wrote:
>
> Jamie, Alex, Brett,
>
> We need to reach consensus on the  element and role="form" mapping.
>
> Can we agree on the following? :
>
> 1. that the IA2 IDL supports IA2_ROLE_LANDMARK and IA2_ROLE_FORM (so that
> old versions of FF and other applications using the form role can still
> work with ATs)
> 2. For Firefox updates here on out the  element and role="form" map
> to IA2_ROLE_LANDMARK and xml-roles="form"
>
> This way AT vendors can check if something is a landmark to determine if
> something is a landmark and then expose xml-roles="form"
>
> Eventually, it would be better to not have to make an exception for the
> Form role when all the other landmark roles are represented as
> IA2_ROLE_LANDMARK with xml-roles="form"
>
> This and the other discussion items of the last 2 weeks are holding up 3
> working groups - ARIA, HTML, and SVG.
>
>
>
> Rich Schwerdtfeger
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

You're right. An element referred by aria-errormessage can be an alert of
live region and thus should be announced by a screen reader, when it pops
up. In this case, it seems the screen reader may need to find a context
element, and if this is true, then the reverse relation is needed.

aria-details are different, since they are more like labels and
descriptions, and I guess thus they should be skipped when navigating the
virtual buffer. That suggests that aria-details either needs a role (or
xml-roles object attribute) or a reverse relation.

On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis <ble...@vfo-group.com> wrote:

> Hi,
>
> Is that documented somewhere?
>
> I read through the information on error and I don’t see anything about AT
> skipping error messages if encountering them while reading through the
> virtual buffer.
>
> Have I misunderstood something?
>
> Thanks,
>
> Brett
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 8:02 AM
> *To:* Brett Lewis <ble...@vfo-group.com>
> *Cc:* Richard Schwerdtfeger <sch...@us.ibm.com>; ja...@nvaccess.org;
> jdi...@igalia.com; accessibility-...@lists.linux-foundation.org
> *Subject:* Re: Reverse relationships
>
>
>
> Hi, Brett.
>
> Can you please elaborate your use case? My understanding is AT skips
> error/details, if the user encounters them, but announce them, when the
> user navigates to an element related with error/details. Why would AT need
> to find a related element by error/details?
>
> Thanks.
>
> Alex.
>
>
>
> On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis <ble...@vfo-group.com> wrote:
>
> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <
> ble...@vfo-group.com>; jdi...@igalia.com
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Reverse relationships
>
>
>
> We need agreement:
>
>
>
> Should the error message and details relationships have reverse mappings?
>
>
>
> Rich
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

I'd say we need have the reverse relations in both of specs (IA2 and UAIG)
and implemented in the browsers, iff there's a valid use case for them, and
intentions from screen readers to implement them.

On Wed, Sep 7, 2016 at 8:44 AM, Richard Schwerdtfeger 
wrote:

> To be clear, we would not document them in the mapping specification if
> they are not implemented.
>
> When I say add them later I am referring to the mapping spec. and
> browsers. However, doing that has ramifications for AT vendors.
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh 
> To: Dominic Mazzoni , Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc: accessibility-...@lists.linux-foundation.org
> Subject: Re: [Accessibility-ia2] Reverse relationships
> Date: Wed, Sep 7, 2016 12:26 AM
>
>
> That's fair. The only problem is that if they're documented in the mapping
> spec, browsers are technically non-compliant if they don't implement.
>
> On 7/09/2016 2:58 PM, Dominic Mazzoni wrote:
>
> Is there any reason we shouldn't *define* the reverse relationships now?
> Browsers can choose not to implement them now for performance reasons, and
> AT can choose to ignore them.
>
>
> On Tue, Sep 6, 2016 at 7:16 PM Richard Schwerdtfeger 
> wrote:
>
> Jamie,
>
>
> Well you can add reverse relationships later if it becomes an issue. The
> only problem with adding it later is you will also then need to test if
> that reverse relation ship exists and what to do with older browsers that
> won't have the relationship.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh 
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com,
> ble...@freedomscientific.com, jdi...@igalia.com
> Cc: accessibility-...@lists.linux-foundation.org
> Subject: Re: Reverse relationships
> Date: Tue, Sep 6, 2016 7:34 PM
>
>
> As I noted previously:
>
>
>
>
>
> 5. Reverse relations may well be useful in the future. However, if they're
> a potential perf problem, I agree it makes sense to wait until we have a
> use case, so long as implementers accept that this use case may one day
> arise.
>
>
>
>
>
> Right now, we have no plans to implement a "jump to field for error
> message" command or similar. Perhaps we will one day, but it seems flawed
> to sacrifice performance for something no one is using yet.
>
> Jamie
>
> On 7/09/2016 5:56 AM, Richard Schwerdtfeger wrote:
>
> We need agreement:
>
> Should the error message and details relationships have reverse mappings?
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

Hi, Brett.

Can you please elaborate your use case? My understanding is AT skips
error/details, if the user encounters them, but announce them, when the
user navigates to an element related with error/details. Why would AT need
to find a related element by error/details?

Thanks.
Alex.


On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis  wrote:

> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <
> ble...@vfo-group.com>; jdi...@igalia.com
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Reverse relationships
>
>
>
> We need agreement:
>
>
>
> Should the error message and details relationships have reverse mappings?
>
>
>
> Rich
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 Role Landmark

[Alexander Surkov]

I definitely agree that IA2 needs a flexible mechanism to expose roles, I'm
just not sure it should be xml-roles object attribute.

On Thu, Aug 25, 2016 at 11:15 AM, Rich Schwerdtfeger <richsch...@gmail.com>
wrote:

> Alex, those object attributes should have been included in IA2 a long time
> ago. I in no way see these as a hack. Eclipse uses them too.
>
> Sent from my iPhone
>
> On Aug 25, 2016, at 9:49 AM, Alexander Surkov <surkov.alexan...@gmail.com>
> wrote:
>
> This is true, however xml-roles is not standard attribute in IA2, it's
> rather a browser specific hack to expose the semantics, that otherwise was
> missed. So if the API provides a way to expose an element semantics more
> fully, then I'd say it's the way to go.
>
> Having said that, I'm also concerned about backward-compatibility issue.
>
> On Thu, Aug 25, 2016 at 10:37 AM, Joanmarie Diggs <jdi...@igalia.com>
> wrote:
>
>> Sorry for being spammy, but with respect to the loss of semantics: The
>> type of landmark is still being exposed via object attribute. So I'll
>> still know if an ATK_ROLE_LANDMARK is a form, or navigation, or 
>>
>> On 08/25/2016 10:24 AM, Joanmarie Diggs wrote:
>> > Hi Alex, all.
>> >
>> > I don't recall saying "kill the form role" in ATK. We have no plans to
>> > deprecate ATK_ROLE_FORM. Instead, I believe I said something along the
>> > lines of the following:
>> >
>> > Q: Should HTML's form element be treated like a landmark for the
>> >    purposes of navigation?
>> >
>> > If Yes: Map it to ATK_ROLE_LANDMARK
>> > If No: Continue mapping it to ATK_ROLE_FORM
>> >
>> > --joanie
>> >
>> > On 08/25/2016 10:08 AM, Alexander Surkov wrote:
>> >> I don't think Jamie argues that FORM is not a landmark. The point is
>> >> that FORM is a form and also a landmark. IA2 provides a special FORM
>> >> role, which is used both for ARIA and HTML currently, and adopted by
>> >> browsers and screen readers.
>> >>
>> >> If we use weaker role for forms, then we loose semantics as Jamie
>> >> pointed out, and we make a not backward compatible change. All JAWS and
>> >> other commercial screen reader users will have to buy a new screen
>> >> reader version.
>> >>
>> >> ATK gained this role, because it doesn't have a mechanism to fetch all
>> >> landmarks on a page other than query it by role. And thus they are ok
>> to
>> >> sacrifice ATK form role for performance reasons I think. Note, ATK
>> world
>> >> doesn't have so acute problem of backward compatibility as IA2 has, so
>> >> they have a larger room for changes. IA2 landmark role is a ATK toll to
>> >> keep IA2 compatible with, this is a primary reason, if I do understand
>> >> that right. However I'm not confident too that we should take ATK path
>> >> and kill a form role too.
>> >>
>> >> On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan
>> >> <stefan.schna...@sap.com <mailto:stefan.schna...@sap.com>> wrote:
>> >>
>> >> Hi James,
>> >>
>> >> __ __
>> >>
>> >> currently Jaws treats forms like regions as landmarks, i.e. showing
>> >> them in its landmarks dialog, too. They do this for reason, page
>> >> structure is very clearly revealed by this. I consider this as a
>> >> strong feature and do not like this changed.
>> >>
>> >> __ __
>> >>
>> >> The logic behind that is the pragmatic thinking that forms are
>> >> landmark-like, too. And a “navigation” landmark can contain fairly
>> >> complex content, too, not just a list of links.
>> >>
>> >> __ __
>> >>
>> >> Best Regards
>> >>
>> >> Stefan
>> >>
>> >> __ __
>> >>
>> >> *From:*James Teh [mailto:ja...@nvaccess.org
>> >> <mailto:ja...@nvaccess.org>]
>> >> *Sent:* Donnerstag, 25. August 2016 00:33
>> >> *To:* Rich Schwerdtfeger <richsch...@gmail.com
>> >> <mailto:richsch...@gmail.com>>
>> >> *Cc:* Alexander Surkov <surkov.alexan...@gmail.com
>> >> <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
>> >> <cl...@alum.mit.edu <mailto:cl...@alum.mit.edu>>; Joa

Re: [Accessibility-ia2] IA2 Role Landmark

[Alexander Surkov]

This is true, however xml-roles is not standard attribute in IA2, it's
rather a browser specific hack to expose the semantics, that otherwise was
missed. So if the API provides a way to expose an element semantics more
fully, then I'd say it's the way to go.

Having said that, I'm also concerned about backward-compatibility issue.

On Thu, Aug 25, 2016 at 10:37 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:

> Sorry for being spammy, but with respect to the loss of semantics: The
> type of landmark is still being exposed via object attribute. So I'll
> still know if an ATK_ROLE_LANDMARK is a form, or navigation, or 
>
> On 08/25/2016 10:24 AM, Joanmarie Diggs wrote:
> > Hi Alex, all.
> >
> > I don't recall saying "kill the form role" in ATK. We have no plans to
> > deprecate ATK_ROLE_FORM. Instead, I believe I said something along the
> > lines of the following:
> >
> > Q: Should HTML's form element be treated like a landmark for the
> >purposes of navigation?
> >
> > If Yes: Map it to ATK_ROLE_LANDMARK
> > If No: Continue mapping it to ATK_ROLE_FORM
> >
> > --joanie
> >
> > On 08/25/2016 10:08 AM, Alexander Surkov wrote:
> >> I don't think Jamie argues that FORM is not a landmark. The point is
> >> that FORM is a form and also a landmark. IA2 provides a special FORM
> >> role, which is used both for ARIA and HTML currently, and adopted by
> >> browsers and screen readers.
> >>
> >> If we use weaker role for forms, then we loose semantics as Jamie
> >> pointed out, and we make a not backward compatible change. All JAWS and
> >> other commercial screen reader users will have to buy a new screen
> >> reader version.
> >>
> >> ATK gained this role, because it doesn't have a mechanism to fetch all
> >> landmarks on a page other than query it by role. And thus they are ok to
> >> sacrifice ATK form role for performance reasons I think. Note, ATK world
> >> doesn't have so acute problem of backward compatibility as IA2 has, so
> >> they have a larger room for changes. IA2 landmark role is a ATK toll to
> >> keep IA2 compatible with, this is a primary reason, if I do understand
> >> that right. However I'm not confident too that we should take ATK path
> >> and kill a form role too.
> >>
> >> On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan
> >> <stefan.schna...@sap.com <mailto:stefan.schna...@sap.com>> wrote:
> >>
> >> Hi James,
> >>
> >> __ __
> >>
> >> currently Jaws treats forms like regions as landmarks, i.e. showing
> >> them in its landmarks dialog, too. They do this for reason, page
> >> structure is very clearly revealed by this. I consider this as a
> >> strong feature and do not like this changed.
> >>
> >> __ __
> >>
> >> The logic behind that is the pragmatic thinking that forms are
> >> landmark-like, too. And a “navigation” landmark can contain fairly
> >> complex content, too, not just a list of links.
> >>
> >> __ __
> >>
> >> Best Regards
> >>
> >> Stefan
> >>
> >> __ __
> >>
> >> *From:*James Teh [mailto:ja...@nvaccess.org
> >> <mailto:ja...@nvaccess.org>]
> >> *Sent:* Donnerstag, 25. August 2016 00:33
> >> *To:* Rich Schwerdtfeger <richsch...@gmail.com
> >> <mailto:richsch...@gmail.com>>
> >> *Cc:* Alexander Surkov <surkov.alexan...@gmail.com
> >> <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
> >> <cl...@alum.mit.edu <mailto:cl...@alum.mit.edu>>; Joanmarie Diggs
> >> <jdi...@igalia.com <mailto:jdi...@igalia.com>>; IA2 List
> >> <accessibility-...@lists.linux-foundation.org
> >> <mailto:accessibility-...@lists.linux-foundation.org>>; ARIA
> Working
> >> Group <public-a...@w3.org <mailto:public-a...@w3.org>>; Steven
> >> Faulkner <faulkner.st...@gmail.com <mailto:faulkner.st...@gmail.com
> >>
> >> *Subject:* Re: [Accessibility-ia2] IA2 Role Landmark
> >>
> >> __ __
> >>
> >> Hi Rich,
> >>
> >> __ __
> >>
> >> I understand the reason for the use of the landmark role for
> >> role="form". However, I disagree with the HTML form element being
> >> map

Re: [Accessibility-ia2] IA2 Role Landmark

[Alexander Surkov]

Hi, Joanie.

I'd say HTML form is a landmark as any other form in the world, but I let
judge others on this.

If there's no use case for ATK form role, then what is a reason to keep it?

On Thu, Aug 25, 2016 at 10:24 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:

> Hi Alex, all.
>
> I don't recall saying "kill the form role" in ATK. We have no plans to
> deprecate ATK_ROLE_FORM. Instead, I believe I said something along the
> lines of the following:
>
> Q: Should HTML's form element be treated like a landmark for the
>purposes of navigation?
>
> If Yes: Map it to ATK_ROLE_LANDMARK
> If No: Continue mapping it to ATK_ROLE_FORM
>
> --joanie
>
> On 08/25/2016 10:08 AM, Alexander Surkov wrote:
> > I don't think Jamie argues that FORM is not a landmark. The point is
> > that FORM is a form and also a landmark. IA2 provides a special FORM
> > role, which is used both for ARIA and HTML currently, and adopted by
> > browsers and screen readers.
> >
> > If we use weaker role for forms, then we loose semantics as Jamie
> > pointed out, and we make a not backward compatible change. All JAWS and
> > other commercial screen reader users will have to buy a new screen
> > reader version.
> >
> > ATK gained this role, because it doesn't have a mechanism to fetch all
> > landmarks on a page other than query it by role. And thus they are ok to
> > sacrifice ATK form role for performance reasons I think. Note, ATK world
> > doesn't have so acute problem of backward compatibility as IA2 has, so
> > they have a larger room for changes. IA2 landmark role is a ATK toll to
> > keep IA2 compatible with, this is a primary reason, if I do understand
> > that right. However I'm not confident too that we should take ATK path
> > and kill a form role too.
> >
> > On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan
> > <stefan.schna...@sap.com <mailto:stefan.schna...@sap.com>> wrote:
> >
> > Hi James,
> >
> > __ __
> >
> > currently Jaws treats forms like regions as landmarks, i.e. showing
> > them in its landmarks dialog, too. They do this for reason, page
> > structure is very clearly revealed by this. I consider this as a
> > strong feature and do not like this changed.
> >
> > __ __
> >
> > The logic behind that is the pragmatic thinking that forms are
> > landmark-like, too. And a “navigation” landmark can contain fairly
> > complex content, too, not just a list of links.
> >
> > __ __
> >
> > Best Regards
> >
> > Stefan
> >
> > __ __
> >
> > *From:*James Teh [mailto:ja...@nvaccess.org
> > <mailto:ja...@nvaccess.org>]
> > *Sent:* Donnerstag, 25. August 2016 00:33
> > *To:* Rich Schwerdtfeger <richsch...@gmail.com
> > <mailto:richsch...@gmail.com>>
> > *Cc:* Alexander Surkov <surkov.alexan...@gmail.com
> > <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
> > <cl...@alum.mit.edu <mailto:cl...@alum.mit.edu>>; Joanmarie Diggs
> > <jdi...@igalia.com <mailto:jdi...@igalia.com>>; IA2 List
> > <accessibility-...@lists.linux-foundation.org
> > <mailto:accessibility-...@lists.linux-foundation.org>>; ARIA Working
> > Group <public-a...@w3.org <mailto:public-a...@w3.org>>; Steven
> > Faulkner <faulkner.st...@gmail.com <mailto:faulkner.st...@gmail.com
> >>
> > *Subject:* Re: [Accessibility-ia2] IA2 Role Landmark
> >
> > __ __
> >
> > Hi Rich,
> >
> > __ __
> >
> > I understand the reason for the use of the landmark role for
> > role="form". However, I disagree with the HTML form element being
> > mapped to the landmark role because semantics are lost. The fact
> > that something is a form has more semantic value than just being a
> > landmark. Still, if the spec already requires this, I guess we have
> > little choice but to comply at this stage.
> >
> >
> > Jamie
> >
> > On 25/08/2016 3:08 AM, Rich Schwerdtfeger wrote:
> >
> > Jamie,  
> >
> > __ __
> >
> > The point is we want ALL the landmarks to be treated the same
> > way for ATVs. So, first we determine that it is a landmark. Then
> > we go to xml-roles to determine the type of landmark. 
> >
> > __ __
> >
> > Otherwise,

Re: [Accessibility-ia2] IA2 Role Landmark

[Alexander Surkov]

I don't think Jamie argues that FORM is not a landmark. The point is that
FORM is a form and also a landmark. IA2 provides a special FORM role, which
is used both for ARIA and HTML currently, and adopted by browsers and
screen readers.

If we use weaker role for forms, then we loose semantics as Jamie pointed
out, and we make a not backward compatible change. All JAWS and other
commercial screen reader users will have to buy a new screen reader version.

ATK gained this role, because it doesn't have a mechanism to fetch all
landmarks on a page other than query it by role. And thus they are ok to
sacrifice ATK form role for performance reasons I think. Note, ATK world
doesn't have so acute problem of backward compatibility as IA2 has, so they
have a larger room for changes. IA2 landmark role is a ATK toll to keep IA2
compatible with, this is a primary reason, if I do understand that right.
However I'm not confident too that we should take ATK path and kill a form
role too.

On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan <stefan.schna...@sap.com>
wrote:

> Hi James,
>
>
>
> currently Jaws treats forms like regions as landmarks, i.e. showing them
> in its landmarks dialog, too. They do this for reason, page structure is
> very clearly revealed by this. I consider this as a strong feature and do
> not like this changed.
>
>
>
> The logic behind that is the pragmatic thinking that forms are
> landmark-like, too. And a “navigation” landmark can contain fairly complex
> content, too, not just a list of links.
>
>
>
> Best Regards
>
> Stefan
>
>
>
> *From:* James Teh [mailto:ja...@nvaccess.org]
> *Sent:* Donnerstag, 25. August 2016 00:33
> *To:* Rich Schwerdtfeger <richsch...@gmail.com>
> *Cc:* Alexander Surkov <surkov.alexan...@gmail.com>; Joseph Scheuhammer <
> cl...@alum.mit.edu>; Joanmarie Diggs <jdi...@igalia.com>; IA2 List <
> accessibility-...@lists.linux-foundation.org>; ARIA Working Group <
> public-a...@w3.org>; Steven Faulkner <faulkner.st...@gmail.com>
> *Subject:* Re: [Accessibility-ia2] IA2 Role Landmark
>
>
>
> Hi Rich,
>
>
>
> I understand the reason for the use of the landmark role for role="form".
> However, I disagree with the HTML form element being mapped to the landmark
> role because semantics are lost. The fact that something is a form has more
> semantic value than just being a landmark. Still, if the spec already
> requires this, I guess we have little choice but to comply at this stage.
>
>
> Jamie
>
> On 25/08/2016 3:08 AM, Rich Schwerdtfeger wrote:
>
> Jamie,
>
>
>
> The point is we want ALL the landmarks to be treated the same way for
> ATVs. So, first we determine that it is a landmark. Then we go to xml-roles
> to determine the type of landmark.
>
>
>
> Otherwise, we need a special case for a form. That is what we are trying
> to avoid. For these reasons ATK/ATSPI created a landmark role first.
>
>
>
> The HTML the form element now uses the ARIA mappings for the form role.
> See "Use WAI-ARIA mapping” under the form element. This is for all
> platforms.
>
>
>
> https://rawgit.com/w3c/aria/master/html-aam/html-aam.html
>
>
>
> We do understand that non-browser applications may still use the older
> Form role mapping as would older browser versions. It is for these reasons
> that our definition of deprecation is that it has not gone a way but rather
> it is going to this new preferred mapping.
>
>
>
> Best,
>
>
>
> Rich
>
>
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
>
>
>
>
> On Aug 23, 2016, at 7:35 PM, James Teh <ja...@nvaccess.org> wrote:
>
>
>
> If you believe that role="form" has no semantic value other than being a
> landmark, then let's go ahead and map it to IA2_ROLE_LANDMARK. On the other
> hand, the HTML form tag *does* have semantic value other than being a
> landmark, so I'd argue it should be IA2_ROLE_FORM.
>
>
>
> On 24/08/2016 5:22 AM, Rich Schwerdtfeger wrote:
>
> We are not asking that IA2_ROLE_FORM be deprecated altogether. Even with
> ARIA we have some attributes that re deprecated but that is meant so that
> there will be a replacement solution. An example is the drag and drop aria
> properties. For ARIA browser conformance testing to exit Candidate
> Recommendation we will be testing for IA2_ROLE_LANDMARK on form roles.
>
>
>
> Rich Schwerdtfeger
>
>
>
>
>
>
>
> On Aug 18, 2016, at 9:56 PM, James Teh <ja...@nvaccess.org> wrote:
>
>
>
> On 11/08/2016 2:58 AM, Alexander Surkov wrote:
>
> 1) adding IA2_ROLE_LANDMARK and
>
> Yes.
>
>
> 2) deprecating IA2_

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

now has two more things it has to fetch for *every
> single object that gets focus*. This is >yet another perf problem.
>
> Error messages are not the same as extended descriptions and we don't want
> the same functionality to duplicated with error messages as I described
> above. The need for error messages arose many major companies rendering
> visible, popup, error messages for each invalid form entry. They want to
> have people with disabilities get access to each error messages associated
> with the invalid control and they want to also have access to the hidden
> aria-describedby help information they provide for that control. So,
> stomping on one in favor of the other is a very bad experience. They are
> indeed distinct and separate concepts.
>
> >3. That said, since the no description/no stringification decision has
> already been made (despite the concerns above which I raised months ago),
> relations is the only mapping that >doesn't violate the spec.
>
> See above. I hope I have addressed most of your concerns.
>
> >4. Since we're not stringifying as part of description, it does not make
> sense to map these to the describedBy relation. Thus, we need two new
> relations.
>
> ok
>
> >5. Reverse relations may well be useful in the future. However, if
> they're a potential perf problem, I agree it makes sense to wait until we
> have a use case, so long as implementers accept >that this use case may one
> day arise.
>
> Joanie Diggs asked for reverse relationships as she wants to be able to
> traverse back to the source. She is on CC and will be back from vacation
> next week.
>
> Best,
> Rich
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh <ja...@nvaccess.org> <ja...@nvaccess.org>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com
> Cc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com
> Subject: Re: aria-details and aria-errormessage mapping
> Date: Thu, Aug 18, 2016 9:45 PM
>
>
> Hi.
>
>
> I've already stated my view on this and asked several questions, but it
> seems key decisions have already been made, despite a lack of clarification
> around the concerns I've raised. Given that this has basically become a
> circular time sink of an argument, I'll provide a final summary of my
> thoughts.
>
> 1. With regard to stringification, I still haven't seen a single solid
> justification for why errormessage and details are different to description
> from a user perspective. It's been argued that users should be able to get
> to the content and read it in its full semantic glory, but no one has
> pointed out a use case for why that is actually necessary for, say, an
> error message. Surely, the desired UX for a screen reader is that it should
> read the error message when it appears, not force the user to press some
> key to jump there and review it. If we want to read the message, we need to
> stringify it... and crawling the tree to stringify it ourselves is going to
> be a hideous perf problem.
> 2. Having errormessage/details as completely separate concepts from
> description means an AT now has two more things it has to fetch for *every
> single object that gets focus*. This is yet another perf problem.
> 3. That said, since the no description/no stringification decision has
> already been made (despite the concerns above which I raised months ago),
> relations is the only mapping that doesn't violate the spec.
> 4. Since we're not stringifying as part of description, it does not make
> sense to map these to the describedBy relation. Thus, we need two new
> relations.
> 5. Reverse relations may well be useful in the future. However, if they're
> a potential perf problem, I agree it makes sense to wait until we have a
> use case, so long as implementers accept that this use case may one day
> arise.
>
> Thanks,
> Jamie
>
> On 19/08/2016 7:21 AM, Richard Schwerdtfeger wrote:
>
> We *cannot* map aria-errormessage or aria-details to a string description.
> That is absolutely prohibited in the aria specification. It is not to be
> stringified. Neither is aria-details. Also, in the aria spec. if
> aria-details and aria-describedby cannot be mapped separately aria-details
> takes precedence.
>
> These are intended to be references so that we can also get access to the
> structural markup.
>
> Now, if you are going to overload the description relationships we need
> something on the target that indicates they are an error or an extended
> description. We need to have the distinctions. Object attributes are an
> option.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
>

Re: [Accessibility-ia2] Fwd: IA2 Role Landmark

[Alexander Surkov]

Jamie, please review the change [1] at your earliest convenience:
* add landmark role
* no form role deprecation for now (we should open issue against HTML a11y
mapping guide, and possibly revisit ARIA change)

Please feel free to merge the branch if it looks good.

Thanks.
Alex.

[1]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=87d4e3be9b9029974db2c37113db5c16210e8566

On Thu, Aug 18, 2016 at 10:56 PM, James Teh <ja...@nvaccess.org> wrote:

> On 11/08/2016 2:58 AM, Alexander Surkov wrote:
>
>> 1) adding IA2_ROLE_LANDMARK and
>>
> Yes.
>
> 2) deprecating IA2_ROLE_FORM?
>>
> I'd argue that there is more semantic value in a "form" than just the fact
> that it is a landmark. This probably doesn't apply to ARIA (at least for
> now), since role="form" is defined as only a landmark. However, I'd argue
> it does apply to the HTML form tag. So, I'm fine t not use IA2_ROLE_FORM
> for ARIA role="form", but I'm dubious about deprecating it altogether,
> including for the HTML form tag.
> Jamie
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

I'd love to hear Jamie on this honestly, but his wording was:

"

To me, it sounds like errormessage just makes the rules slightly simply
to make life simpler for authors; errormessage isn't presented unless
invalid is true, errormessage must be visible to be presented, etc. That
might be fair enough. However, that doesn't mean it's an entirely
fundamentally separate concept, and thus, there's a good argument for
mapping it to description in a11y APIs (with appropriate rules)."

Do we a real example/scenario where AT has to know that a message on the
screen is an error message, and this knowledge would improve the user
experience?

On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:

> Yes, we heard. So, we need to be able to differentiate an associated error
> message from a help descriptions. So, you could have a second aria-details
> relationship in the list of relationships as it would not be stringified (a
> necessity), BUT you would need to put something on the target ID container
> to indicate to the AT that it is an error message. Otherwise you need a
> different relationship. If you are not having reverse relationships and AT
> vendors would provide a mechanism to go back to the element that was
> invalid then you would be fine. The use cases we have seen in practices is
> that multiple form elements become invalid and each has an associated popup
> error message.
>
> We cannot mix descriptions and error messages and the error messages must
> be visible to all users to be mapped.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>
> Subject: Re: aria-details and aria-errormessage mapping
> Date: Wed, Aug 10, 2016 12:48 PM
>
> Note, Jamie has been objecting against new relation for aria-errormessage
> [1].
>
> [1] https://lists.linuxfoundation.org/pipermail/accessibility-
> ia2/2016-April/002046.html
>
> On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
> All reverse relations go at performance/memory cost, I would introduce
> them iff AT needs them. I'm not sure I see a valid scenario, when they were
> useful, thus deferring a decision to Joanie and Jamie, who knows more about
> AT internal gear than me.
>
> On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
> wrote:
>
> Those would be great. What would you have for reverse relationships?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>, Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc:
> Subject: aria-details and aria-errormessage mapping
> Date: Tue, Aug 9, 2016 2:12 PM
>
> Hi.
>
> ARIA 1.1 got two relation-like attributes: aria-details [1] and
> aria-errormessage [2], used to connect an element with content providing
> extra info. Rich mentioned that these attributes are likely need new
> IAccessible2 relations to expose them, which sounds reasonable. If that's
> the case, then we should end up with something like:
>
> An object containing details for the target object.
> IA2_RELATION_DETAILS
> An object containing an error message for the target object.
> IA2_RELATION_ERROR_MESSAGE
> Thanks.
> Alex.
>
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
>
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

Note, Jamie has been objecting against new relation for aria-errormessage
[1].

[1]
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-April/002046.html

On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> All reverse relations go at performance/memory cost, I would introduce
> them iff AT needs them. I'm not sure I see a valid scenario, when they were
> useful, thus deferring a decision to Joanie and Jamie, who knows more about
> AT internal gear than me.
>
> On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
> wrote:
>
>> Those would be great. What would you have for reverse relationships?
>>
>>
>>
>> Rich Schwerdtfeger
>>
>>
>>
>> - Original message -
>> From: Alexander Surkov <surkov.alexan...@gmail.com>
>> To: "accessibility-ia2@lists.linuxfoundation.org" <
>> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
>> ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>, Richard
>> Schwerdtfeger/Austin/IBM@IBMUS
>> Cc:
>> Subject: aria-details and aria-errormessage mapping
>> Date: Tue, Aug 9, 2016 2:12 PM
>>
>> Hi.
>>
>> ARIA 1.1 got two relation-like attributes: aria-details [1] and
>> aria-errormessage [2], used to connect an element with content providing
>> extra info. Rich mentioned that these attributes are likely need new
>> IAccessible2 relations to expose them, which sounds reasonable. If that's
>> the case, then we should end up with something like:
>>
>> An object containing details for the target object.
>> IA2_RELATION_DETAILS
>> An object containing an error message for the target object.
>> IA2_RELATION_ERROR_MESSAGE
>> Thanks.
>> Alex.
>>
>> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
>> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
>>
>>
>>
>>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] ARIA feed role

[Alexander Surkov]

Let's go with ROLE_SYSTEM_GROUPING then until Jamie has objections.

On Wed, Aug 10, 2016 at 8:54 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:

> Hey Alex.
>
> On 08/10/2016 08:27 AM, Alexander Surkov wrote:
>
> > 1) IA2_ROLE_FEED
>
> Piñeiro might kill me if I tell him I need a new role in ATK. ;) But if
> we absolutely need one for IA2, I can pursue that. However:
>
> > 2) ROLE_SYSTEM_GROUPING with xml-roles='feed'
>
> Is what we want for ATK (i.e. ATK_ROLE_PANEL). Because a list whose
> children are not listitem elements is confusing. You have to descend the
> accessibility tree just in case there are some listitems there. And you
> still may not find them in the end.
>
> > 3) ROLE_SYSTEM_LIST with xml-roles='feed'
>
> No thank you.
>
> > Joanie, how have ATK approached to this?
>
> ATK_ROLE_PANEL as indicated above. But Rich only asked for my mappings
> recently and I've not actually done anything specific in Orca for the
> feed role. So as long as you don't want to make it a list, I'm willing
> to discuss an alternative mapping if doing so is helpful.
>
> --joanie
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] ARIA feed role

[Alexander Surkov]

So I can see three options

1) IA2_ROLE_FEED

It will take time to be picked up by browsers and screen readers.

2) ROLE_SYSTEM_GROUPING with xml-roles='feed'

Probably more backward compatible option, as existing AT, that have no
'feed' support, can announce 'grouping'.

3) ROLE_SYSTEM_LIST with xml-roles='feed'

It's good in terms of group position info, but articles as children may be
confusing for AT.

Joanie, how have ATK approached to this?

Thanks.
Alex.


On Tue, Aug 9, 2016 at 4:57 PM, Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:

> Alex,
>
> A feed is a list of articles that is infinitely scrolling. There is no
> end. This was requested by Facebook and it could also apply to Twitter and
> Instagram.
>
> Each article can have an aria-posinset and  aria-setsize. Also, the
> presence of the feed role would indicate new keyboard navigation.
>
> So, this is why it is not a "list per say".  However, you could make it a
> list with an xml-roles="feed" value but there would be no listitems. They
> would be articles.
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov <surkov.alexan...@gmail.com>
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie
> Diggs <jdi...@igalia.com>
> Cc:
> Subject: ARIA feed role
> Date: Tue, Aug 9, 2016 2:30 PM
>
> Hi.
>
> A new 'feed' role was introduced by ARIA 1.1 [1], which is a list of
> feeds. I'm curious if the new ARIA role deserves a new IA2 role or we can
> go with MSAA ROLE_SYSTEM_LIST role as we do for ARIA directory role [2] and
> [3].
>
> Thanks.
> Alex.
>
> [1] https://www.w3.org/TR/wai-aria-1.1/#feed
> [2] https://www.w3.org/TR/wai-aria-1.1/#directory
> [3] https://www.w3.org/TR/wai-aria-implementation/#mapping_role_table
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

Hi.

ARIA 1.1 got two relation-like attributes: aria-details [1] and
aria-errormessage [2], used to connect an element with content providing
extra info. Rich mentioned that these attributes are likely need new
IAccessible2 relations to expose them, which sounds reasonable. If that's
the case, then we should end up with something like:

An object containing details for the target object.

IA2_RELATION_DETAILS

An object containing an error message for the target object.

IA2_RELATION_ERROR_MESSAGE

Thanks.
Alex.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 Role Landmark

[Alexander Surkov]

I'm totally up to keep APIs in sync but if no one is going to use the
feature, then there's no much benefit of implementing it. I defer to Jamie
on this.

As a side note, it sounds a bit wired that the assistive technologies on
Windows have to support a new role to make Orca faster. Please don't get me
wrong, I'm exited to have fast Orca, but I feel there's something wrong
with the approach.

On Tue, Feb 23, 2016 at 3:16 PM, Rich Schwerdtfeger 
wrote:

> Copy what Joanie stated. This would also help as we start moving toward a
> common api in ARIA 2.0.
>
> I would prefer that platforms diverge less. It sounds like it will not
> break anything for you.
>
> Rich
>
>
> Rich Schwerdtfeger
>
>
>
>
> On Feb 23, 2016, at 12:34 PM, Joanmarie Diggs  wrote:
>
> Hey Jamie.
>
> At least on my platform, getting all of the ROLE_LANDMARK objects (e.g.
> for a list of landmarks dialog) via AtspiCollection is a lot more
> performant than getting all the elements and then filtering out the
> non-landmarks (99-100% of the set) via object attribute. The xml-roles
> value remains useful for those cases where it matters what type of
> landmark a particular element happens to be.
>
> If you don't have a similar advantage on your platform, then I guess the
> justification is the desire to keep our completely different platforms
> as aligned as possible. And if you accept ROLE_LANDMARK, the next time
> one of us has to compromise/give in, it will be my turn. 
>
> --joanie
>
> On 02/22/2016 08:37 PM, James Teh wrote:
>
> Hi Rich,
>
> I don't necessarily have an objection to introducing a new role, but I
> also don't quite follow the justification.
>
> I follow that region became a subclass of landmark. However, I don't
> follow how this changes the "landmark" role; if anything, it changes the
> "region" role. And even then, the region role never had its own IA2 role
> in the first place. Furthermore, since we have to look at xml-roles
> anyway (as we always have, despite my objection years ago, but that's an
> entirely different story), I don't follow how the landmark role is useful.
>
> I'm sure I'm missing something here. Can you enlighten me? :)
>
> Thanks,
> Jamie
>
> On 20/02/2016 9:37 AM, Richard Schwerdtfeger wrote:
>
> Hi Alex,
>
> I am following up on this earlier discussion regarding needing an
> IA2_LANDMARK_ROLE
>
>
> http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-January/001993.html
>
>
> A fundamental change from ARIA 1.0 is we now have the role “region” as
> a descendant of a role of landmark:
>
> https://www.w3.org/TR/wai-aria-1.1/#region
>
>
> So, this is the revised set of landmarks:
>
> https://www.w3.org/TR/wai-aria-1.1/#landmark_roles
>
> The reason for this is developers have been using labelledy regions as
> landmarks and in HTML5 we now have a section landmark which will
> default to a role of “region” if it has a label on it.
>
> Given this change we would like this a new IA2_ROLE_LANDMARK that
> matches the landmark role we now have in ATK/ATSPI. The xml-roles
> attribute would take the value of the actual role as we know.
>
> Is there any objection to introducing this new role in IA2?
>
> We are trying to lock down ARIA 1.1 and this is one of the issues we
> need to address.
>
> Thanks,
>
> Rich
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

Ok, done among a few other fixes [1]

[1]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=c5b43ab9ef81793b634695308726671346e3ad83

On Wed, Dec 16, 2015 at 5:34 PM, James Teh <ja...@nvaccess.org> wrote:

> On 17/12/2015 4:09 AM, Alexander Surkov wrote:
>
>> Don't we need an extra aMaxRanges argument? It seems any other
>> array-related method has it.
>>
> The older methods (e.g. IAccessible2::relations) used client allocated
> arrays, but this makes life a bit difficult. These did need a max argument.
> The newer methods (e.g. IAccessibleTableCell::columnHeaderCells) are server
> allocated arrays which the client frees with CoTaskMemFree. These do not
> need a max argument. However, we *should* document that the parameter is a
> server allocated array and needs to be freed with CoTaskMemFree, just as we
> do for IAccessibleTableCell::columnHeaderCells.
>
> Jamie
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

a small change to make things clearer?

"However, in case of selection, when the user selects backwards (e.g.
pressing shift+left arrow in a text field), the start of the range is the
active point, as the user moves this to manipulate the selection."

On Sun, Dec 6, 2015 at 11:02 PM, James Teh <ja...@nvaccess.org> wrote:

> Hi Alex,
>
> The interface/method looks fine. Just one comment on the documentation:
>
> + * One of the range points is an anchor, a start of the range, and
> another one
> + * is a range end, which typically coincides with the user focus.
>
>
> I think we need to be careful about the words "start" and "end" here. In
> the usual case, anchor will be less than active. However, if the user is
> selecting backwards, active will be less than anchor. Even if active <
> anchor, I still see the lesser number as being the "start" of the "range".
> This is one of the reasons I preferred start, end and a boolean for the
> anchor/active determination, though I realise that seems like a pointless
> waste of bytes.
>
> Maybe we could say something like:
>
> The "anchor" is one point of the range and typically remains constant. The
> other point is the "active" point, which typically corresponds to the
> user's focus or point of interest. The user moves the active point to
> expand or collapse the range. In most cases, anchor is the start of the
> range and active is the end. However, when selecting backwards (e.g.
> pressing shift+left arrow in a text field), the start of the range is the
> active point, as the user moves this to manipulate the selection.
>
>
> The other problem is that unless you're dealing with something like
> selection, the terms anchor and active don't make a huge amount of sense,
> since neither point is the "anchor". I realise that selection is the
> primary use case, but it seems like this range struct is trying to be more
> generic than this.
>

we could name them start and end then, and document that in case of
selection 'start' is a selection anchor, 'end' is a active selection
boundary.


>
> Jamie
>
> On 4/12/2015 10:57 PM, Alexander Surkov wrote:
>
> Jamie, Andres, all could you please to take a look at the proposal and
> comment it out here?
> Thanks!
> Alex.
>
> [1]
> http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=85deaf1a1514f0c5e6a59e8c9b6606abfb6e6813
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

Jamie, Andres, all could you please to take a look at the proposal and
comment it out here?
Thanks!
Alex.

[1]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=85deaf1a1514f0c5e6a59e8c9b6606abfb6e6813

On Fri, Nov 13, 2015 at 4:01 PM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> Ok, so here's a change [1]. Looking for your feedback.
> Thanks!
> Alexander.
>
> [1]
> http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=85deaf1a1514f0c5e6a59e8c9b6606abfb6e6813
>
> On Fri, Nov 13, 2015 at 1:05 PM, Andres Gonzalez <andgo...@adobe.com>
> wrote:
>
>> Hello Alex and Jamie:
>>
>>
>>
>> >>>
>>
>> I'm good to keep that out of box for now as long as we do a generic
>> approach so later we can update just docs.
>>
>> Andres, what do you think?
>>
>> How we are going to proceed with active/anchor boundaries? Let's move
>> with a proper naming vs one extra member?
>>
>> <<<
>>
>>
>>
>>
>>
>> Agree with Alex that we should get the method signature as generic as
>> possible, so that we don’t have to change it later. But we can have the
>> first implementation focusing on the text only case and make sure it works
>> well there, since this is the case that motivated the addition of the new
>> method. I believe we’ll find that it will be easily extensible to selection
>> of objects in a container. Also agree to renaming the member vars to
>> anchorOffset/activeOffset, or Index instead of offset. As for range
>> boundaries, I like to follow the convention in C++ ranges and many other
>> ranges where the start is inclusive and the end is exclusive. For instance,
>> in the string “abc”, range (0,1) = “a”, range (2,3) = “c”, range
>> (0,lengthof(“abc”)) = “abc”, etc. range (x,x) is an empty or degenerated
>> range for any x and means no selection.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> --Andres.
>>
>>
>>
>> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
>> *Sent:* Thursday, November 12, 2015 10:35 AM
>> *To:* James Teh
>> *Cc:* Andres Gonzalez; accessibility-ia2@lists.linuxfoundation.org
>> *Subject:* Re: [Accessibility-ia2] a new method to retrieve the selection
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 11, 2015 at 5:12 PM, James Teh <ja...@nvaccess.org> wrote:
>>
>> On 12/11/2015 12:28 AM, Alexander Surkov wrote:
>>
>>
>>
>> I guess it isn't an edge case after all. I was originally confused by
>> using child indexes in the case of no text, as this seems strange to me.
>>
>>
>>
>> I'm not sure where we are on this idea. Do you think we'd rather drop it?
>>
>> Personally, I'd rather have a separate mechanism to deal with selected
>> objects in a container. I think it's just going to get too confusing
>> otherwise.
>>
>>
>>
>> I'm good to keep that out of box for now as long as we do a generic
>> approach so later we can update just docs.
>>
>> Andres, what do you think?
>>
>> How we are going to proceed with active/anchor boundaries? Let's move
>> with a proper naming vs one extra member?
>>
>>
>>
>>
>>
>> I don't really follow this. As I understand it, selection starts are
>> inclusive and selection ends are exclusive. So, why are we talking about
>> "before" a child? If you have 4 children and children 2 and 3 are selected,
>> IMO, the start offset should be 1 (the selection starts at the second
>> child) and the end offset should be 3 (the selection ends after the third
>> child). Maybe this is just terminology; it doesn't really matter so long as
>> we agree on the numbers. :)
>>
>>
>>
>> I'm not sure I have clear understanding how values differs for inclusive
>> and exclusive end boundaries. Can you give me please an example for, say,
>> when a container has one child and it is selected, i.e selection starts
>> before it and ends after it?
>>
>> The way I think of text (and maybe this is wrong visually), if you have
>> the string "a" and you select it, the selection starts *at* the "a" and
>> ends *after* it. So, in that case, start would be 0 and end would be 1.
>> Similarly, if you have just one child, start would be 0 and end would be 1.
>> I have a feeling we're actually talking about the same thing, but you see
>> the seleciton as starting "before", not "at".
>>
>> Jamie
>>
>>
>> --
>>
>> James Teh
>>
>> Executive Director, NV Access Limited
>>
>> Ph +61 7 3149 3306
>>
>> www.nvaccess.org
>>
>> Facebook: http://www.facebook.com/NVAccess
>>
>> Twitter: @NVAccess
>>
>> SIP: ja...@nvaccess.org
>>
>>
>>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-current thread on ia2

[Alexander Surkov]

On Wed, Dec 2, 2015 at 9:36 AM, Joseph Scheuhammer 
wrote:

> Hi Jamie,
>
> Thanks for making that clearer.  Comments inline.
>
> On 2015-12-01 7:42 PM, James Teh wrote:
>
>> The active state in the IA2 spec says:
>>
>>  This state can be used to indicate the current active item in a
>>> container, even
>>>   if the container itself is not currently active. In other words this
>>> would indicate
>>>   the item that will get focus if you tab to the container.
>>>
>>
>> So, it basically maps to aria-activedescendant.
>>
>
> Put another way, the item has focus when the container is active. That's
> not what aria-current means.  The current item may or may not have focus,
> and can remain current even when another item in the container has focus.
> IA2's active state has a different meaning than ATK's, apparently.
>

Right, that's unfortunate but ATK and IA2 differ. If I remember Joanie's
words then ATK state has been introduced a while ago and used somewhere in
GTK. Same is more or less valid for IA2. As Jamie said IA2 can be changed
but we need to make sure nobody depends on the implementation.

On the other hand it's probably ok to not sync ATK and IA2 for this
particular case. IA2 has a way for a fast way to obtain object attributes,
so perfromance is not an issue for IA2 unlike ATK, thus IA2 doesn't
necessary need a state in addition to the object attribute.


> One question:  the quote above says the item has the active state when
> it's container is non-active.  Then when the container becomes active, the
> item then has a focused state.  Does it keep the active state after it has
> gained focus?  I know, the question is likely irrelevant to the current
> discussion, but I am curious about details.


Correct, iirc active state is exposed in Firefox not depending on the focus.


>
>
> That technically conflicts  somewhat with the idea of aria-current. The
>> question is whether ATs currently use this solely for its currently
>> documented purpose. (FWIW, NVDA doesn't use it at all yet.) If they do,
>> this needs to be discussed with other AT vendors or a new state needs ot be
>> used.
>>
>> Jamie
>>
>
> --
> joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>- G. Bernhardt -
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-current thread on ia2

[Alexander Surkov]

On Wed, Dec 2, 2015 at 6:05 PM, James Teh <ja...@nvaccess.org> wrote:

> On 3/12/2015 6:20 AM, Alexander Surkov wrote:
>
>> Right, that's unfortunate but ATK and IA2 differ. If I remember Joanie's
>> words then ATK state has been introduced a while ago and used somewhere in
>> GTK. Same is more or less valid for IA2. As Jamie said IA2 can be changed
>> but we need to make sure nobody depends on the implementation.
>>
> IMO, even the wording for the ATK active state is misleading, but that's
> an entirely different issue and it's not really relevant because everyone
> in ATK land knows what it means. :)
>
> On the other hand it's probably ok to not sync ATK and IA2 for this
>> particular case. IA2 has a way for a fast way to obtain object attributes,
>> so perfromance is not an issue for IA2 unlike ATK, thus IA2 doesn't
>> necessary need a state in addition to the object attribute.
>>
> Not necessarily, but using object attributes for things that should
> probably really be states is also pretty ugly. :)


aria-current is an enumeration like aria-autocomplete, which is exposed an
object attribute, no states in addition.



> As for "a fast way to obtain object attributes", that's controversial. We
> can either obtain one or all. All is slow on the server side, while one
> requires far too many calls, which is hideous for an out-proc client.
> Out-proc clients are actually better off fetching all states because the
> server side penalty is far less than the penalty of multiple cross-proc
> calls.
>

true, anyway I'm not sure I like the idea to use states to workaround a
slowness of object attributes, after all states require computations too,
and I think we are not guaranteed that their computation is always faster
on an object. Also we have only 64bits for states, it's not too much.


>
> Jamie
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-current thread on ia2

[Alexander Surkov]

On Wed, Dec 2, 2015 at 9:23 PM, James Teh <ja...@nvaccess.org> wrote:

> On 3/12/2015 9:51 AM, Alexander Surkov wrote:
>
>> aria-current is an enumeration like aria-autocomplete, which is exposed
>> an object attribute, no states in addition.
>>
> Ah. I missed/forgot that aria-current is not just true/false; just re-read
> the spec. In that case, I agree it probably doesn't make sense to go
> through the trouble of introducing a new state.
>
> Just a correction, though: aria-autocomplete does expose
> IA2_STATE_SUPPORTS_AUTOCOMPLETION; at least, it does in Firefox.


caught me :)


>
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

Ok, so here's a change [1]. Looking for your feedback.
Thanks!
Alexander.

[1]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=85deaf1a1514f0c5e6a59e8c9b6606abfb6e6813

On Fri, Nov 13, 2015 at 1:05 PM, Andres Gonzalez <andgo...@adobe.com> wrote:

> Hello Alex and Jamie:
>
>
>
> >>>
>
> I'm good to keep that out of box for now as long as we do a generic
> approach so later we can update just docs.
>
> Andres, what do you think?
>
> How we are going to proceed with active/anchor boundaries? Let's move with
> a proper naming vs one extra member?
>
> <<<
>
>
>
>
>
> Agree with Alex that we should get the method signature as generic as
> possible, so that we don’t have to change it later. But we can have the
> first implementation focusing on the text only case and make sure it works
> well there, since this is the case that motivated the addition of the new
> method. I believe we’ll find that it will be easily extensible to selection
> of objects in a container. Also agree to renaming the member vars to
> anchorOffset/activeOffset, or Index instead of offset. As for range
> boundaries, I like to follow the convention in C++ ranges and many other
> ranges where the start is inclusive and the end is exclusive. For instance,
> in the string “abc”, range (0,1) = “a”, range (2,3) = “c”, range
> (0,lengthof(“abc”)) = “abc”, etc. range (x,x) is an empty or degenerated
> range for any x and means no selection.
>
>
>
> Best regards,
>
>
>
> --Andres.
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Thursday, November 12, 2015 10:35 AM
> *To:* James Teh
> *Cc:* Andres Gonzalez; accessibility-ia2@lists.linuxfoundation.org
> *Subject:* Re: [Accessibility-ia2] a new method to retrieve the selection
>
>
>
>
>
>
>
> On Wed, Nov 11, 2015 at 5:12 PM, James Teh <ja...@nvaccess.org> wrote:
>
> On 12/11/2015 12:28 AM, Alexander Surkov wrote:
>
>
>
> I guess it isn't an edge case after all. I was originally confused by
> using child indexes in the case of no text, as this seems strange to me.
>
>
>
> I'm not sure where we are on this idea. Do you think we'd rather drop it?
>
> Personally, I'd rather have a separate mechanism to deal with selected
> objects in a container. I think it's just going to get too confusing
> otherwise.
>
>
>
> I'm good to keep that out of box for now as long as we do a generic
> approach so later we can update just docs.
>
> Andres, what do you think?
>
> How we are going to proceed with active/anchor boundaries? Let's move with
> a proper naming vs one extra member?
>
>
>
>
>
> I don't really follow this. As I understand it, selection starts are
> inclusive and selection ends are exclusive. So, why are we talking about
> "before" a child? If you have 4 children and children 2 and 3 are selected,
> IMO, the start offset should be 1 (the selection starts at the second
> child) and the end offset should be 3 (the selection ends after the third
> child). Maybe this is just terminology; it doesn't really matter so long as
> we agree on the numbers. :)
>
>
>
> I'm not sure I have clear understanding how values differs for inclusive
> and exclusive end boundaries. Can you give me please an example for, say,
> when a container has one child and it is selected, i.e selection starts
> before it and ends after it?
>
> The way I think of text (and maybe this is wrong visually), if you have
> the string "a" and you select it, the selection starts *at* the "a" and
> ends *after* it. So, in that case, start would be 0 and end would be 1.
> Similarly, if you have just one child, start would be 0 and end would be 1.
> I have a feeling we're actually talking about the same thing, but you see
> the seleciton as starting "before", not "at".
>
> Jamie
>
>
> --
>
> James Teh
>
> Executive Director, NV Access Limited
>
> Ph +61 7 3149 3306
>
> www.nvaccess.org
>
> Facebook: http://www.facebook.com/NVAccess
>
> Twitter: @NVAccess
>
> SIP: ja...@nvaccess.org
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

On Wed, Nov 11, 2015 at 5:12 PM, James Teh <ja...@nvaccess.org> wrote:

> On 12/11/2015 12:28 AM, Alexander Surkov wrote:
>
>
> I guess it isn't an edge case after all. I was originally confused by
> using child indexes in the case of no text, as this seems strange to me.
>
> I'm not sure where we are on this idea. Do you think we'd rather drop it?
>
> Personally, I'd rather have a separate mechanism to deal with selected
> objects in a container. I think it's just going to get too confusing
> otherwise.
>

I'm good to keep that out of box for now as long as we do a generic
approach so later we can update just docs.

Andres, what do you think?

How we are going to proceed with active/anchor boundaries? Let's move with
a proper naming vs one extra member?


> I don't really follow this. As I understand it, selection starts are
> inclusive and selection ends are exclusive. So, why are we talking about
> "before" a child? If you have 4 children and children 2 and 3 are selected,
> IMO, the start offset should be 1 (the selection starts at the second
> child) and the end offset should be 3 (the selection ends after the third
> child). Maybe this is just terminology; it doesn't really matter so long as
> we agree on the numbers. :)
>
>
> I'm not sure I have clear understanding how values differs for inclusive
> and exclusive end boundaries. Can you give me please an example for, say,
> when a container has one child and it is selected, i.e selection starts
> before it and ends after it?
>
> The way I think of text (and maybe this is wrong visually), if you have
> the string "a" and you select it, the selection starts *at* the "a" and
> ends *after* it. So, in that case, start would be 0 and end would be 1.
> Similarly, if you have just one child, start would be 0 and end would be 1.
> I have a feeling we're actually talking about the same thing, but you see
> the seleciton as starting "before", not "at".
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

On Wed, Nov 4, 2015 at 2:09 AM, James Teh <ja...@nvaccess.org> wrote:

> On 4/11/2015 3:14 AM, Alexander Surkov wrote:
>
> An edge case is a text document, but where the selection start or end is a
> graphic. In that case, I think the returned object should actually be the
> parent and the offset should be the relevant offset of the embedded object.
>
>
> I'm not sure I follow why this is an edge case and where the problem is,
> because if a document has an image as a child, and the document implements
> text interface, then the returned object should be the document and offset
> should be the text offset for embedded character for the image accessible.
>
> I guess it isn't an edge case after all. I was originally confused by
> using child indexes in the case of no text, as this seems strange to me.
>

I'm not sure where we are on this idea. Do you think we'd rather drop it?


>
> I don't quite follow what you mean by *before* the child. So, for the
> second child, would the offset be 1?
>
> opposite :) if the offset is 1 then the selection is right before the
> second child, if the offset is 2 then selection is right after the second
> child and right before a third child.
>
> I don't really follow this. As I understand it, selection starts are
> inclusive and selection ends are exclusive. So, why are we talking about
> "before" a child? If you have 4 children and children 2 and 3 are selected,
> IMO, the start offset should be 1 (the selection starts at the second
> child) and the end offset should be 3 (the selection ends after the third
> child). Maybe this is just terminology; it doesn't really matter so long as
> we agree on the numbers. :)
>

I'm not sure I have clear understanding how values differs for inclusive
and exclusive end boundaries. Can you give me please an example for, say,
when a container has one child and it is selected, i.e selection starts
before it and ends after it?


>
> I'm actually wondering whether, in this case, the returned object should
> just be the relevant child; i.e. startOffset and endOffset are just
> irrelevant.
>
> say, you have an object with number of children, and the selection
> contains the last child only, i.e it starts before the child and ends after
> it. How would you describe the selection having no start/endOffsets?
>
> That's a good point. I agree my proposal can't handle this case. However,
> I'd suggest then that perhaps this interface just doesn't really suit
> selection for non-text cases. We're already hitting confusion with the term
> "offset", and for non-text cases, it seems more logical to me to just have
> a way to enumerate selected objects.
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] a new method to retrieve the selection

[Alexander Surkov]

Here's outcome email from Mozilla bug [1] discussion, where Jamie (NVDA)
and me concluded that IAccessible2 environment would benefit from having a
new method to retrieve text/content selection in perfromant way. The idea
is to supplement IAccesible2_2::accessibleWithCaret method, introduced for
caret, by similar method for selection getting.

The proposed method may look like

typedef struct IA2Range {
  AccessibleText* start;
  long startOffset;
  AccessibleText* end;
  long endOffset;
} IA2Range;

selectionRanges([out, size_is(,*nRanges) IA2Range **ranges,
[out, retval] long *nRanges);

which returns an array of all continues selection ranges within the given
accessible, and hosted by new IAccessible2_3 inherited from IAccessible2_2.

Another idea from that thread was to keep newly added interfaces unfrozen,
until we are confident the interface will need no change in the nearest
future. So we'll be adding new methods into the end of the interface, to
keep binary compatibility.

Please let me know your thinking.

Thank you.
Alexander.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1052866
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 mapping of aria-current

[Alexander Surkov]

I see, apparently I worked with out of dated ATK spec which didn't say
about non windows :)

I sent a question to Joanie in the previous email.

ATK has object attribute change event iirc.

On Mon, Aug 31, 2015 at 4:36 PM, Joseph Scheuhammer 
wrote:

> Hi Alex,
>
> I agree on 'current' object attribute, not sure ACTIVE_STATE is a proper
>> mapping for both IA2 and ATK (ATK defines it as "Indicates a window is
>> currently the active window"). Why do you think it's worth to set up the
>> state?
>>
>
> Short answer:  because Joanie told me so. :-)
>
> Longer answer:  the documentation for ACTIVE_STATE says more than just the
> currently active window .  It also notes:
> - It is used to indicate the active subelement within a container.
> - It is *not* used to indicate focus.  Use STATE_FOCUSED to indicate focus.
> - It is *not* used to indicate selection. Use STATE_SELECTED to indicate
> selection.
>
> See
> https://developer.gnome.org/atk/unstable/atk-AtkState.html#AtkStateType.
> You'll have to scroll down to and look for ATK_STATE_ACTIVE since there is
> no direct link.
>
> Also, the state is useful for state change events.  See:
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#event-aria-current.
> I should have pointed to the event mappings in my last email since they the
> IA2 mappings need confirmation there too.
>
> Thanks.
>
>
> --
> joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>- G. Bernhardt -
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 mapping of aria-current

[Alexander Surkov]

So it's just for performance? If you had convenient and fast way to obtain
object attributes then you wouldn't need a state?

On Mon, Aug 31, 2015 at 5:22 PM, Joanmarie Diggs <jdi...@igalia.com> wrote:

> On 08/31/2015 05:12 PM, Alexander Surkov wrote:
> > Hi, Joanie. I guess ATK didn't want to have active state just because an
> > item is focusable or selectable rather than deny a focsuable/selctable
> > items being active, otherwise I don't see a point for this; also it has
> > to be in conflict with aria-current. Anyway regardless what ATK has,
> > what is the point of having both object attribute and state for same
> thing?
>
> If aria-current's value were a boolean, then the state would be
> sufficient -- and much more performant than the object attribute.
> However, aria-current has a value through which an author can indicate
> the context in which the element is current. This, of course, cannot be
> exposed via the state. But checking every last element's object
> attributes on the off chance it has aria-current set on it is not ideal.
> The state indicates it's worth getting the object attributes.
>
> --joanie
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] aria-errormessage

[Alexander Surkov]

Hi. It looks like we need a new relation to expose aria-errormessage which
refers to an element containing the error message. Should we have a pair
IA2_RELATION_ERROR_FOR/BY for that?

THanks!
Alexander.

[1] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-errormessage
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Fw: ARIA 1.1 feature status aria-rowspan and aria-colspan

[Alexander Surkov]

On Wed, Jul 29, 2015 at 7:57 AM, Richard Schwerdtfeger sch...@us.ibm.com
wrote:

 Yes, that is possible. He also said that would be hideous. :-)


he probably needs time to get ok with it :)



 One concern is the growth of object attributes and the mechanism to get
 them. Perhaps we need a new interface to object attributes like a hashing
 table.


IA2 has attribute method
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible2__2.html#a6cda836322d18e6206e10291b395aa55.
Not yet implemented though.



 Rich

 Sent from my iPad

 On Jul 28, 2015, at 2:32 PM, Alexander Surkov surkov.alexan...@gmail.com
 wrote:

 I'd say the problem is in restrictions of IAccessibleTable as it describes
 the continuous model only, while ARIA allows to have gaps in tables. So
 if a table has a gap and spanning right before the gap then we should use a
 mechanism other than IAccessibleTable. Jamie suggested to use object
 attributes which sounds reasonable.
 Alex.

 On Tue, Jul 28, 2015 at 10:40 AM, Richard Schwerdtfeger sch...@us.ibm.com
  wrote:

 I am continuing the discussion on the list. It sounds like we have two
 models - contiguous rows/columns vs. author specified.

 Should we say that if the author is going to provide row and column spans
 that user agents NOT compute the indices? IOW, It must all be left up to
 the author.

 It sounds like the issue is that we are fighting with trying to compute
 the results vs. what the author is putting in.

 Rich


 Rich Schwerdtfeger
 - Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/28/2015 09:31
 AM -

 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Richard Schwerdtfeger/Austin/IBM@IBMUS
 Cc: Brett Lewis ble...@freedomscientific.com, David Bolter 
 dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
 Date: 07/28/2015 09:19 AM
 Subject: Re: ARIA 1.1 feature status
 --



 Hi, Rich. Here's Jamie's example [1] where putting ARIA span into
 IAccessibleTable interface may be not trivial. I suggest to move discussion
 to IA2 channel if possible.

 [1]
 *http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html*
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html

 On Tue, Jul 28, 2015 at 8:38 AM, Richard Schwerdtfeger 
 *sch...@us.ibm.com* sch...@us.ibm.com wrote:

That does not make sense. It is essentially the same attribute.


Rich Schwerdtfeger

M2.gifAlexander Surkov ---07/27/2015 08:16:15 PM---They are exposed
via IAccessibleTable interface which seems to be inapplicable for ARIA
spanning.

From: Alexander Surkov *surkov.alexan...@gmail.com*
surkov.alexan...@gmail.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Brett Lewis *ble...@freedomscientific.com*
ble...@freedomscientific.com, David Bolter *dbol...@mozilla.com*
dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
Date: 07/27/2015 08:16 PM


Subject: Re: ARIA 1.1 feature status
--



They are exposed via IAccessibleTable interface which seems to be
inapplicable for ARIA spanning.

On Mon, Jul 27, 2015 at 8:59 PM, Richard Schwerdtfeger 
*sch...@us.ibm.com* sch...@us.ibm.com wrote:
   How do you expose rowspan and colspan for HTML tables?


   Rich Schwerdtfeger

   M2.gifAlexander Surkov ---07/27/2015 04:06:58 PM---Hi, Brett.
   All but colspan/rowspan are implemented by Nightly.
   arai-colcount/rowcount/colindex/rowin


   From: Alexander Surkov *surkov.alexan...@gmail.com*
   surkov.alexan...@gmail.com
   To: Brett Lewis *ble...@freedomscientific.com*
   ble...@freedomscientific.com
   Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank
   DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter 
   *dbol...@mozilla.com* dbol...@mozilla.com
   Date: 07/27/2015 04:06 PM
   Subject: Re: ARIA 1.1 feature status
   --



   Hi, Brett. All but colspan/rowspan are implemented by Nightly.
   arai-colcount/rowcount/colindex/rowindex are exposed as GroupPosition 
 on
   cells and rows. There's no understanding yet on how to expose
   aria-colspan/rowspan [1].

   [1]
   
 *http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html*
   
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html

   On Mon, Jul 27, 2015 at 4:49 PM, Brett Lewis 
   *ble...@freedomscientific.com* ble...@freedomscientific.com
   wrote:
  Hi Alex,
  I am starting work on JAWS support for the new ARIA 1.1
  features.
  I wanted to see where you are w/r/t Firefox support for these.
  I was thinking of starting with the table related roles, does
  Firefox support these?
  How about:
  aria-colcount
  aria-rowcount
  aria-colindex
  aria-rowindex

Re: [Accessibility-ia2] Fw: ARIA 1.1 feature status aria-rowspan and aria-colspan

[Alexander Surkov]

I'd say the problem is in restrictions of IAccessibleTable as it describes
the continuous model only, while ARIA allows to have gaps in tables. So
if a table has a gap and spanning right before the gap then we should use a
mechanism other than IAccessibleTable. Jamie suggested to use object
attributes which sounds reasonable.
Alex.

On Tue, Jul 28, 2015 at 10:40 AM, Richard Schwerdtfeger sch...@us.ibm.com
wrote:

 I am continuing the discussion on the list. It sounds like we have two
 models - contiguous rows/columns vs. author specified.

 Should we say that if the author is going to provide row and column spans
 that user agents NOT compute the indices? IOW, It must all be left up to
 the author.

 It sounds like the issue is that we are fighting with trying to compute
 the results vs. what the author is putting in.

 Rich


 Rich Schwerdtfeger
 - Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/28/2015 09:31 AM
  -

 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Richard Schwerdtfeger/Austin/IBM@IBMUS
 Cc: Brett Lewis ble...@freedomscientific.com, David Bolter 
 dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
 Date: 07/28/2015 09:19 AM
 Subject: Re: ARIA 1.1 feature status
 --



 Hi, Rich. Here's Jamie's example [1] where putting ARIA span into
 IAccessibleTable interface may be not trivial. I suggest to move discussion
 to IA2 channel if possible.

 [1]
 *http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html*
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html

 On Tue, Jul 28, 2015 at 8:38 AM, Richard Schwerdtfeger 
 *sch...@us.ibm.com* sch...@us.ibm.com wrote:

That does not make sense. It is essentially the same attribute.


Rich Schwerdtfeger

[image: Inactive hide details for Alexander Surkov ---07/27/2015
08:16:15 PM---They are exposed via IAccessibleTable interface which 
 se]Alexander
Surkov ---07/27/2015 08:16:15 PM---They are exposed via IAccessibleTable
interface which seems to be inapplicable for ARIA spanning.

From: Alexander Surkov *surkov.alexan...@gmail.com*
surkov.alexan...@gmail.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Brett Lewis *ble...@freedomscientific.com*
ble...@freedomscientific.com, David Bolter *dbol...@mozilla.com*
dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
Date: 07/27/2015 08:16 PM


Subject: Re: ARIA 1.1 feature status
--



They are exposed via IAccessibleTable interface which seems to be
inapplicable for ARIA spanning.

On Mon, Jul 27, 2015 at 8:59 PM, Richard Schwerdtfeger 
*sch...@us.ibm.com* sch...@us.ibm.com wrote:
   How do you expose rowspan and colspan for HTML tables?


   Rich Schwerdtfeger

   [image: Inactive hide details for Alexander Surkov ---07/27/2015
   04:06:58 PM---Hi, Brett. All but colspan/rowspan are implemented by 
 Ni]Alexander
   Surkov ---07/27/2015 04:06:58 PM---Hi, Brett. All but colspan/rowspan 
 are
   implemented by Nightly. arai-colcount/rowcount/colindex/rowin

   From: Alexander Surkov *surkov.alexan...@gmail.com*
   surkov.alexan...@gmail.com
   To: Brett Lewis *ble...@freedomscientific.com*
   ble...@freedomscientific.com
   Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank
   DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter 
   *dbol...@mozilla.com* dbol...@mozilla.com
   Date: 07/27/2015 04:06 PM
   Subject: Re: ARIA 1.1 feature status
   --



   Hi, Brett. All but colspan/rowspan are implemented by Nightly.
   arai-colcount/rowcount/colindex/rowindex are exposed as GroupPosition on
   cells and rows. There's no understanding yet on how to expose
   aria-colspan/rowspan [1].

   [1]
   
 *http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html*
   
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html

   On Mon, Jul 27, 2015 at 4:49 PM, Brett Lewis 
   *ble...@freedomscientific.com* ble...@freedomscientific.com
   wrote:
  Hi Alex,
  I am starting work on JAWS support for the new ARIA 1.1 features.
  I wanted to see where you are w/r/t Firefox support for these.
  I was thinking of starting with the table related roles, does
  Firefox support these?
  How about:
  aria-colcount
  aria-rowcount
  aria-colindex
  aria-rowindex
  aria-colspan
  aria-rowspan

  Do you have a general time line for all the ARIA 1.1 features?
  (even just an ordering of which features will be implemented first)?
  Do you have a bug record for these?
  Thanks for any info you might have.
  Brett


  Brett Lewis
  Software Developer
  Freedom Scientific, Inc
 *727-299

Re: [Accessibility-ia2] rowspan and colspan

[Alexander Surkov]

So we do have two use cases.

#1 Example of spanned cells in a table having missed column
div role=table aria-colcount=4
  div role=row
div role=cell aria-colindex=1 aria-colspan=2cell 1/div
div role=cell aria-colindex=4cell 4/div
  /div
  div role=row
div role=cell aria-colindex=1 aria-colspan=2cell 1/div
div role=cell aria-colindex=2cell 2/div
div role=cell aria-colindex=4cell 4/div
  /div
/div

#2 Example of spanned cells
div role=table
  div role=row
div role=cell aria-colspan=2cell 1/div
  /div
  div role=row
div role=cellcell 1/div
div role=cellcell 2/div
  /div
/div

Do I understand correct that the table interface should take into account
of aria-colspan in case #2, and it should ignore it in case #3?


On Sun, Jun 28, 2015 at 9:13 PM, James Teh ja...@nvaccess.org wrote:

 I think it should. However, this shows up an edge case. What if the author
 provides non-contiguous rows or columns, as aria-row/colindex allows? For
 example, suppose only columns 1 and 4 were in the DOM (using
 aria-colindex), but column 1 had a span of 2 (using aria-colspan). Column 4
 in the DOM would be mapped to column 2 in the table interface (since the
 table interface is always contiguous). In this case, the table interface
 should not expose column extent for column 1, since that would suggest that
 column 2 in the table interface was spanned (which is column 4 in the DOM).
 So now we need a secondary way of exposing aria-colspan, perhaps an object
 attribute. This is really quite hideous. FWIW, I don't know of any API that
 can handle this; UIA can't either.

 Jamie


 On 27/06/2015 8:15 AM, Alexander Surkov wrote:

 Hey. ARIA introduced aria-rowspan and aria-colspan attributes [1] and
 [2]. Should be they exposed as part of IAccessibleTable interface, i.e.
 as col/row extents?

 [1] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-rowspan
 [2] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-colspan



 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 James Teh
 Executive Director, NV Access Limited
 Ph +61 7 3149 3306
 www.nvaccess.org
 Facebook: http://www.facebook.com/NVAccess
 Twitter: @NVAccess
 SIP: ja...@nvaccess.org
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] STATE_INDETERMINATE as a means to indicate things like unknowable set size?

[Alexander Surkov]

On Tue, Sep 30, 2014 at 7:22 PM, James Teh ja...@nvaccess.org wrote:

 On 30/09/2014 2:32 AM, Joanmarie Diggs wrote:

 Given a large data set where the set size is not known (e.g. gmail's 1
 of about 120), we need a way to be able to communicate the known set
 size along with the fact that the total is not (yet) known. One proposal
 has been to expose this via something like 120+. The problem with that
 is it means most of the time set size is a number, except for when it's
 a string one needs to parse. Seems like a less-than-ideal situation to me.

 Agreed. It's even worse in IA2 because it has a groupPosition property
 which uses ints, not strings, so it would be impossible to expose the +
 in that case.

  In ATK, we happily have STATE_INDETERMINATE which seems like it would
 fit the bill nicely,making it possible for quantifiable things like set
 size to remain numbers and giving implementors a means to indicate the
 size is indeterminate. In chatting with Alex Surkov about this, he
 seemed to think this was a reasonable approach. The only problem was
 that the ATK docs specifically said this state was for tri-state
 checkboxes in the mixed state.

 In IA2, this is exposed using MSAA's STATE_SYSTEM_MIXED (since IA2 is a
 superset of MSAA). While we *could* use this, there are two problems:
 1. We can't update the documentation for MSAA, and even if we could, this
 wouldn't make sense because MSAA doesn't have groupPosition. I guess we
 could document an addition to STATE_SYSTEM_MIXED in the IA2 spec, but
 that's rather ugly.
 2. This could be confusing for clients which support MSAA but not IA2.
 Therefore, we'd probably need to introduce a new IA2 state.


STATE_INDETERMINATE? both for tri-state checkboxes and groups of unknown
size?



  I just solved that with new docs. This
 change has just been committed. [1] So we're good.

 I'm not sure if this is an issue for ATK, but one problem I see is that in
 IA2, it's possible for any control to be checkable. This could include an
 item which has groupPosition. So, for example, what if there were a
 tri-state checkable tree item? How would you tell whether it were tri-state
 or in an indeterminate group?

 Jamie

 --
 James Teh
 Executive Director, NV Access Limited
 Ph +61 7 3149 3306
 www.nvaccess.org
 Facebook: http://www.facebook.com/NVAccess
 Twitter: @NVAccess
 SIP: ja...@nvaccess.org

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-roledescription

[Alexander Surkov]

It's not said by the spec but could the author use custom value for @role
attribute and @aria-roledescription both, for example,
div role=hyperbutton aria-roledescription=hyperspace button.

In that case extendedRole would be used to contain @role value,
localizedExtendedRole would expose value of aria-roledescription.

On Sun, Jun 28, 2015 at 7:22 PM, James Teh ja...@nvaccess.org wrote:

 It's technically not quite a match for localizedExtendedRole, as that
 would suggest there was an extendedRole. However, I
 thinklocalizedExtendedRole is still a better match than object attributes.
 It may be helpful to update the spec to note that localizedExtendedRole can
 be valid even if extendedRole is NULL.

 Jamie


 On 27/06/2015 7:47 AM, Alexander Surkov wrote:

 ARIA 1.1 introduced aria-roledescription attribute which contains a
 localized version of ARIA role. Would it be a match for
 localizedExtendedRole or should we proceed with object attributes?
 Thanks.
 Alex.

 [1]
 https://rawgit.com/w3c/aria/master/aria/aria.html#aria-roledescription


 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 James Teh
 Executive Director, NV Access Limited
 Ph +61 7 3149 3306
 www.nvaccess.org
 Facebook: http://www.facebook.com/NVAccess
 Twitter: @NVAccess
 SIP: ja...@nvaccess.org
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] rowspan and colspan

[Alexander Surkov]

Hey. ARIA introduced aria-rowspan and aria-colspan attributes [1] and [2].
Should be they exposed as part of IAccessibleTable interface, i.e. as
col/row extents?

[1] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-rowspan
[2] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-colspan
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] aria-roledescription

[Alexander Surkov]

ARIA 1.1 introduced aria-roledescription attribute which contains a
localized version of ARIA role. Would it be a match for
localizedExtendedRole or should we proceed with object attributes?
Thanks.
Alex.

[1] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-roledescription
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] aria-colcount and aria-rowcount mapping

[Alexander Surkov]

Hi. ARIA introduced aria-colcount/rowcount [1], [2] which allows -1 value
that means the number of rows/columns is unknown. Are there ideas how to
expose that?
Thanks.
Alexander.


[1] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-rowcount
[2] https://rawgit.com/w3c/aria/master/aria/aria.html#aria-colcount
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping

[Alexander Surkov]

yeah, that should make a trick. So, groupPosition on a row returns row
count and row index, groupPosition on a cell returns a col count and col
index. Right?

On Wed, Jun 24, 2015 at 8:07 PM, James Teh ja...@nvaccess.org wrote:

 On 25/06/2015 10:02 AM, Alexander Surkov wrote:

 If we kept table interface to reflect actual table structure, and put
 aria row/colcount/index into object attributes, then would it work?

 I guess so, though as I said, it's pretty confusing for implementers.
 Instead of object attributes, could we use groupPosition?

 Jamie


 --
 James Teh
 Executive Director, NV Access Limited
 Ph +61 7 3149 3306
 www.nvaccess.org
 Facebook: http://www.facebook.com/NVAccess
 Twitter: @NVAccess
 SIP: ja...@nvaccess.org
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Fw: Deprecate IA2_TEXT_BOUNDARY_ALL?

[Alexander Surkov]

For the record. Bug 436 (deprecate IA2_TEXT_BOUNDARY_ALL) [1] has been
fixed [2].

[1] https://bugs.linuxfoundation.org/show_bug.cgi?id=436
[2]
http://git.linuxfoundation.org/?p=a11y/ia2.git;a=commitdiff;h=638432d6ff601cfd411b20aa4b2e76eee265fb06

On Mon, May 4, 2015 at 10:28 AM, Alexander Surkov 
surkov.alexan...@gmail.com wrote:

 just in case, bug URLS are:

 https://bugs.linuxfoundation.org/show_bug.cgi?id=436
 https://bugs.linuxfoundation.org/show_bug.cgi?id=437




 On Tue, Apr 20, 2010 at 3:02 PM, Pete Brunet p...@a11ysoft.com wrote:

  Thanks for starting that discussion Car, I opened the following.
 Please review:
 - deprecate IA2_TEXT_BOUNDARY_ALL
   http://bugs.freestandards.org/show_bug.cgi?id=436
 - mention IA2_TEXT_OFFSET_LENGTH (-1) in the methods it applies to
   http://bugs.freestandards.org/show_bug.cgi?id=437

 Thanks, Pete

 Carolyn MacLeod wrote:


 Interesting - thanks for pointing this out!
 I didn't notice the special offsets section:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_generalinfo.html#_specialOffsets
 (actually, I think I read this once a long time ago, but now that I am
 implementing, I am reading method by method. Might be nice to point to this
 in the method doc for each of the 10 methods it applies to, i.e. See also
 [special offsets link]).

 So there are currently 5 ways to get the whole text... even more reason
 to deprecate IA2_TEXT_BOUNDARY_ALL.   :)

 Carolyn



  *Re: [Accessibility-ia2] Deprecate IA2_TEXT_BOUNDARY_ALL?*
   *Michael Curran * to: Accessibility-ia2
 04/15/2010 07:29 PM

 Sent by: *accessibility-ia2-boun...@lists.linuxfoundation.org
 accessibility-ia2-boun...@lists.linuxfoundation.org*




 --



 I'm pretty sure that NVDA sometimes makes use of
 IAccessible::text(0,IA2_TEXT_OFFSET_LENGTH,text)

 Where IA2_TEXT_OFFSET_LENGTH is -1.

 I'm not sure when this was introduced to IA2, but Gecko supports it, not
 sure about Symphony.

 Very useful as it stops the need for calling nCharacters.

 Mick

 On 16/04/2010 7:40 AM, James Teh wrote:
  On 16/04/2010 2:39 AM, Carolyn MacLeod wrote:
  Do AT's use IA2_TEXT_BOUNDARY_ALL?
  We don't. However, see below.
 
  Or do they use IAccessibleText::text(0, length, pbstrText) to retrieve
  all of the text?
  We do this.
 
  2) Technically, we don't need it because IAccessibleText::text(0,
  length, pbstrText) already returns the whole text.
  Note that this requires ATs to make an extra call
  (IAccessibleText::nCharacters) to determine the length. Extra calls do
  matter across process boundaries. We do this anyway, but it's worth
  adding to the discussion.
 
  I am tempted to return E_INVALIDARG if get boundaryType ==
  IA2_TEXT_BOUNDARY_ALL in textAfterOffset and textBeforeOffset. Would
  that break anybody?
  Hmm. That makes it look like the caller is wrong to try to use it when
  it is in the spec. I'd prefer E_NOTIMPL, but I realise that's only
  supposed to be used when the entire method isn't implemented. Are there
  any other options that indicate that this particular request isn't
  implemented?
 
  Jamie
 

 --
 Michael Curran
 email/msn/jabber: m...@kulgan.net
 Skype/Twitter: md_curran
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

 --

 ___
 Accessibility-ia2 mailing 
 listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2


 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2



___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] placeholder mapping

[Alexander Surkov]

I think I'm good to expose HTML and ARIA placeholder attributes via
plaholder object attribute. But I'm not sure I see reasoning of *not*
mapping it into accessible name/description the way what HTML5 spec
suggests.

On Fri, May 1, 2015 at 10:41 AM, Richard Schwerdtfeger sch...@us.ibm.com
wrote:

 The problem with the name computation is that:

 If you use it to compute a name only and then type over it you lose the
 hint. ... e.g. a placeholder value of MMDDYY. The AT can always ask for the
 placeholder value.

 Rich


 Rich Schwerdtfeger

 [image: Inactive hide details for Alexander Surkov ---05/01/2015 09:20:36
 AM---So it seems like we all agree to introduce placeholder o]Alexander
 Surkov ---05/01/2015 09:20:36 AM---So it seems like we all agree to
 introduce placeholder object attribute in IAccessible2. IA2 spec do

 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Joseph Scheuhammer cl...@alum.mit.edu
 Cc: IAccessible2 mailing list 
 accessibility-...@lists.linux-foundation.org, Steve Faulkner 
 faulkner.st...@gmail.com
 Date: 05/01/2015 09:20 AM
 Subject: Re: [Accessibility-ia2] placeholder mapping
 Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
 --



 So it seems like we all agree to introduce placeholder object attribute in
 IAccessible2. IA2 spec doesn't define markup mappings so it doesn't have to
 say about HTML5 placeholder and ARIA aria-placeholder attributes. Anyway,
 it doesn't prevent us from discussing it here :) So are there benefits in
 changing of current HTML5 placeholder mappings into accessible name and
 description?

 Btw, Joseph, I didn't really suggested to change GTK+ mappings :)

 On Thu, Apr 30, 2015 at 12:05 PM, Joseph Scheuhammer *cl...@alum.mit.edu*
 cl...@alum.mit.edu wrote:

On 2015-04-29 7:48 AM, Alexander Surkov wrote:
   I support the idea that the browser should find a best match for
   accessible name and description. Btw, current version of HTML a11y spec
   agrees on it [1]. After all there's backward compatibility issue If
   placeholder is exposed leaving accessible name blank.

   [1]
   
 *http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-calculation*
   
 http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-calculation

That's not backward compatible with the GNOME desktop (GTK+), where
placeholder text is not mapped to an empty accessible name.  Thus, there is
now a mismatch between desktop widgets and widgets within a web page, on
one desktop.


--
joseph.

'Array(16).join(wat - 1) +  Batman!'
   - G. Bernhardt -

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] placeholder mapping

[Alexander Surkov]

Hi, Joanie. I'm fine with that. I suggested this to make it easier for AT
to detect whether placeholder is valuable as a placeholder but as long as
everybody is onboard I don't really mind, especially if the it was in
WebKit for a while.

On Mon, Apr 27, 2015 at 4:22 PM, Joanmarie Diggs jdi...@igalia.com wrote:

 Hey Alex.

 On 04/27/2015 12:58 PM, Alexander Surkov wrote:

 [...]

  Also it's backward compatible approach. So does the following make sense?
 
  1) If placeholder is used to label the control, i.e accessible name is
  not provided otherwise then map placeholder (aria-placeholder) into
  accessible name
  2) Expose placeholder as object attribute on the accessible object if it
  wasn't used as name.

 What about changing 2) to just Expose placeholder as object
 attribute.? In other words, independent of what happens in terms of the
 name mapping. That's what's happening -- and has been happening for
 several years -- in Gtk+ and WebKitGtk for native (non-ARIA) placeholder
 text.

 --joanie



___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] placeholder mapping

[Alexander Surkov]

Hi.

In Firefox HTML placeholder attribute is mapped to accessible name if label
is not provided (either native or ARIA one). Otherwise it's ignored. There
are strong opinions that placeholder needs own mapping since it's separate
concept from the accessible name and AT want to treat it special way.
Because of that aria-placeholder has been introduced [1].

There's number of examples on the web where placeholder is used as a label
and it's reasonable if we continue to map it to accessible name. Also it's
backward compatible approach. So does the following make sense?

1) If placeholder is used to label the control, i.e accessible name is not
provided otherwise then map placeholder (aria-placeholder) into accessible
name
2) Expose placeholder as object attribute on the accessible object if it
wasn't used as name.

Thanks.
Alex.

[1] https://lists.w3.org/Archives/Public/public-pfwg/2015Apr/0032.html
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Need event to fire when a relation is added/removed

[Alexander Surkov]

Thanks, Pete.

Hi, Dominic. Are there any consumers for relation change events? From what
I can tell I was never requested for it by AT vendor iirc.

ATK has generic property changed event and I find it nice, but MSAA has
separate events for most of properties already [1], and I don't see a good
way to implement it in IAccessible2 because of Windows event model.
IAccessible2 has text changed event by newText/oldText hack but it doesn't
really work for out process AT.

We might have OBJECT_CHANGED event, but SHOW/HIDE bundle looks like
appropriate workaround. I'm curious though to hear AT vendors on it.

Thanks.
Alex.

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318066%28v=vs.85%29.aspx


On Mon, Feb 23, 2015 at 11:51 AM, Pete Brunet p...@a11ysoft.com wrote:

  Alex, et al.  FYI

 On 2/23/15 10:29 AM, bugzilla-dae...@bugs.linuxfoundation.org wrote:

 https://bugs.linuxfoundation.org/show_bug.cgi?id=1263

  Bug #: 1263
Summary: Need event to fire when a relation is added/removed
Product: Accessibility
Version: rc
   Platform: All
 OS/Version: All
 Status: NEW
   Severity: normal
   Priority: P2
  Component: IAccessible2
 AssignedTo: p...@a11ysoft.com
 ReportedBy: dmazz...@google.com
 Classification: Unclassified


 I work on Google Chrome's accessibility support. There doesn't seem to be a
 good event to fire on Windows when an IAccessible2 object's relations change,
 i.e. when IAccessible2::relations() would return a different answer than 
 before
 - assuming that no other property of the object happens to change.

 There might be a tiny handful of other object properties that could change 
 that
 don't have a specific associated event, it might be worth auditing the API to
 see.

 The remaining cases are somewhat obscure, so I wonder if instead or in 
 addition
 it might make sense to have an event meaning that *any* property of an object
 changed without specifying which one. As another use for this, if lots of
 properties of an object change at once (name, description, role, etc.) a 
 server
 could fire just one event instead of multiple.



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Need event to fire when a relation is added/removed

[Alexander Surkov]

Hi, Dominic. I agree, those events are needed for API completeness,
probably not so urgent as long as we don't have real use case for those.

Perhaps we could adopt UIA event model since it looks more flexible than
MSAA's one. UIA has property change events [1] which might be used for our
unmapped properties.

Yeah, that's a downside of SHOW/HIDE event approach. It'd be nice to have
something more performant.

Thanks.
Alex.

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/ee671601%28v=vs.85%29.aspx

On Tue, Feb 24, 2015 at 11:25 AM, Dominic Mazzoni dmazz...@google.com
wrote:

 Alex,

 There aren't any consumers for the relation change events I'm aware of.
 This was purely an observation from the perspective of the browser that the
 relations might change and we don't have any way to update.

 Some other properties that might change where it's not obvious to me what
 event should fire:

 IAccessible2::locale (e.g. if the author dynamically adds a lang=fr
 attribute to an element).
 IAccessibleComponent::foreground
 IAccessibleComponent::background
 IAccessibleImage::description

 Again, these are all theoretical - they're just observations of cases we
 encounter in the code where we can't fire an event.

 As for HIDE/SHOW as a workaround, wouldn't that have the effect of causing
 the AT to query the whole subtree? That can be quite expensive, it'd be
 nice to have some solution that makes it clear that only one node has
 changed.

 - Dominic


 On Tue, Feb 24, 2015 at 8:12 AM, Alexander Surkov 
 surkov.alexan...@gmail.com wrote:

 Thanks, Pete.

 Hi, Dominic. Are there any consumers for relation change events? From
 what I can tell I was never requested for it by AT vendor iirc.

 ATK has generic property changed event and I find it nice, but MSAA has
 separate events for most of properties already [1], and I don't see a good
 way to implement it in IAccessible2 because of Windows event model.
 IAccessible2 has text changed event by newText/oldText hack but it doesn't
 really work for out process AT.

 We might have OBJECT_CHANGED event, but SHOW/HIDE bundle looks like
 appropriate workaround. I'm curious though to hear AT vendors on it.

 Thanks.
 Alex.

 [1]
 https://msdn.microsoft.com/en-us/library/windows/desktop/dd318066%28v=vs.85%29.aspx


 On Mon, Feb 23, 2015 at 11:51 AM, Pete Brunet p...@a11ysoft.com wrote:

  Alex, et al.  FYI

 On 2/23/15 10:29 AM, bugzilla-dae...@bugs.linuxfoundation.org wrote:

 https://bugs.linuxfoundation.org/show_bug.cgi?id=1263

  Bug #: 1263
Summary: Need event to fire when a relation is added/removed
Product: Accessibility
Version: rc
   Platform: All
 OS/Version: All
 Status: NEW
   Severity: normal
   Priority: P2
  Component: IAccessible2
 AssignedTo: p...@a11ysoft.com
 ReportedBy: dmazz...@google.com
 Classification: Unclassified


 I work on Google Chrome's accessibility support. There doesn't seem to be a
 good event to fire on Windows when an IAccessible2 object's relations 
 change,
 i.e. when IAccessible2::relations() would return a different answer than 
 before
 - assuming that no other property of the object happens to change.

 There might be a tiny handful of other object properties that could change 
 that
 don't have a specific associated event, it might be worth auditing the API 
 to
 see.

 The remaining cases are somewhat obscure, so I wonder if instead or in 
 addition
 it might make sense to have an event meaning that *any* property of an 
 object
 changed without specifying which one. As another use for this, if lots of
 properties of an object change at once (name, description, role, etc.) a 
 server
 could fire just one event instead of multiple.



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2




___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] IA2_ROLE_TOGGLE_BUTTON is not recommend by spec

[Alexander Surkov]

Hi. IA2 spec doesn't recommend to use TOGGLE_BUTTON role [1]:

BRBNote:/B IA2_ROLE_TOGGLE_BUTTON should not be used.  Instead,
use MSAA's
   ROLE_SYSTEM_PUSHBUTTON and STATE_SYSTEM_PRESSED.

However it's in use in Firefox for years [2]. Note, ATK's toggle button
doesn't have similar wording.

Is there any particular reason of this wording?

Thank you.
Alexander.

[1]
http://accessibility.linuxfoundation.org/a11yspecs/ia2/api/AccessibleRole.idl
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=390284
[3] https://developer.gnome.org/atk/unstable/AtkObject.html
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] New states for HTML meter element

[Alexander Surkov]

Hi.

HTML5 introduced meter element [1], which is basically a progressbar role
but can be in special states:

1) optimal state when value is in optimal rage  (for example, if  low 
optimum  high then value should be in [low, high], if optimum  high then
value should be greater than high.

2) suboptimal state when value is in range next to optimum range (for
example, if low  optimum  high then value  low is suboptimal.

3) subsuboptimal state when value is not neither optimal nor suboptimal for
example if optimum  high but value  low.

Firefox colors these states as green/yellow/red.

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-meter-element

Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=559770
Some examples: http://peter.sh/examples/?/html/meter-progress.html
Try it out: http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_meter

Thanks.
Alex.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Please review the v1.3 update on the IA2 site

[Alexander Surkov]

It'd be good to convert line endings in all files into unix format.



On Fri, May 17, 2013 at 11:02 PM, Pete Brunet p...@a11ysoft.com wrote:


 On 5/17/13 6:04 AM, Alexander Surkov wrote:

  Hi, Pete. It seems linux line endings were changed to windows line
 ending. Was it intentional change?

 Hi Alex, It was not intentional.  It's often a problem in my
 multi-platform environment.  What needs to be changed?

 Pete

  Thank you.
 Alex.


 On Thu, May 16, 2013 at 10:39 PM, Pete Brunet p...@a11ysoft.com wrote:

  Hi Alex, That's right.  I found a couple of very small problems in my
 review yesterday but when I rebuild the zip it not have an effect on the
 code.  I'm going to wait a while to see if anyone else finds any issues
 before I resubmit to the web site.  -Pete


 On 5/16/13 12:32 AM, Alexander Surkov wrote:

  Hi, Pete. Thanks for finishing it! Do I understand right that link for
 downloading IDLs is
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/ia2-api-20130501.zip
 .
  Thank you.
 Alex.


 On Thu, May 16, 2013 at 2:10 PM, Pete Brunet p...@a11ysoft.com wrote:

  The IA2 site has been updated to fix a few things people noticed were
 wrong.  Please take a look and let me know if you find anything that needs
 fixing.

 The top level is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/

 Please ignore the prior zip, ia2-api-20130314.zip.  It will eventually
 disappear.

 The spec is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/

 Pete
 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Object attribute format

[Alexander Surkov]

Hi, Pete. I have Gecko specific example. XUL tree rows and cells provides
set of properties that we want to expose via IA2. For example, it allows to
expose a message info in Thunderbird (like forwarded, replied etc), see
https://bugzilla.mozilla.org/show_bug.cgi?id=448235.

I don't argue that space separated list is preferable. I'd even say that
comma separated list seems more close to IA2 object attributes format. But
the question was raised in that Mozilla bug and I got here for
clarification.

Thanks.
Alex.


On Fri, May 17, 2013 at 11:04 PM, Pete Brunet p...@a11ysoft.com wrote:

  Alex, Can you give us an example of the multi-value case?  As to the
 choice we need more input so far we have that you suggested a space and I
 suggested a comma.  -Pete


 On 5/16/13 11:03 PM, Alexander Surkov wrote:

  So it'd be good to put the format into the spec. Do I understand correct
 that the choice falls at comma separated list?
  Thank you.
 Alex.


  On Fri, May 17, 2013 at 11:44 AM, James Teh ja...@nvaccess.org wrote:

 On 17/05/2013 11:54 AM, Pete Brunet wrote:

 attribute:value1,value2 seems acceptable.

 Agreed.


  Does it implicitly mean that in case of several values the following
 format is expected (as no subattributes were used):
 attribute:value1,value2?

  While the format makes sense, I don't think it's implicit. It isn't
 something I considered while writing NVDA's IA2 attributes parser, so it
 won't handle this without changes. It's probably reasonable that others may
 not have considered it either.

 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2




 ___
 Accessibility-ia2 mailing 
 listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Please review the v1.3 update on the IA2 site

[Alexander Surkov]

We didn't update IA2 files in Firefox for a while so I'm not sure which
version was the change introduced in. (I don't exclude a possibility that
it was a conversion at Firefox side when first IA2 version was checked in
:) ).

I don't mind if win line endings will be used.

Thank you.
Alex.


On Sat, May 18, 2013 at 12:24 AM, Pete Brunet p...@a11ysoft.com wrote:

  Hi Alex, I used grep under Cygwin to look at the 1.2.1 files and they
 also had CRLF line endings.  Here is the grep command I used:
 cd .../api
 grep -IUrl ^M .
 where ^M was entered using Ctrl+V Ctrl+M.
 This technique is from:

 http://stackoverflow.com/questions/73833/how-do-you-search-for-files-containing-dos-line-endings-crlf-with-grep-under-l

 BTW, CR is Ctrl M and LF is Ctrl J

 Are you seeing differences from the prior version?  If so, what
 differences?  If not, is this a change request?

 I'm assuming since we are working in a Win environment that CRLF endings
 would be expected.

 Pete


 On 5/17/13 9:35 AM, Alexander Surkov wrote:

 It'd be good to convert line endings in all files into unix format.



 On Fri, May 17, 2013 at 11:02 PM, Pete Brunet p...@a11ysoft.com wrote:


 On 5/17/13 6:04 AM, Alexander Surkov wrote:

  Hi, Pete. It seems linux line endings were changed to windows line
 ending. Was it intentional change?

  Hi Alex, It was not intentional.  It's often a problem in my
 multi-platform environment.  What needs to be changed?

 Pete

  Thank you.
 Alex.


 On Thu, May 16, 2013 at 10:39 PM, Pete Brunet p...@a11ysoft.com wrote:

  Hi Alex, That's right.  I found a couple of very small problems in my
 review yesterday but when I rebuild the zip it not have an effect on the
 code.  I'm going to wait a while to see if anyone else finds any issues
 before I resubmit to the web site.  -Pete


 On 5/16/13 12:32 AM, Alexander Surkov wrote:

  Hi, Pete. Thanks for finishing it! Do I understand right that link for
 downloading IDLs is
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/ia2-api-20130501.zip
 .
  Thank you.
 Alex.


 On Thu, May 16, 2013 at 2:10 PM, Pete Brunet p...@a11ysoft.com wrote:

  The IA2 site has been updated to fix a few things people noticed were
 wrong.  Please take a look and let me know if you find anything that needs
 fixing.

 The top level is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/

 Please ignore the prior zip, ia2-api-20130314.zip.  It will eventually
 disappear.

 The spec is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/

 Pete
 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G



 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Object attribute format

[Alexander Surkov]

(resending to IA2 list)

Hi.

What is object attribute format is excepted when the server needs to
provide more than one value for the single object attribute.

The IA2 doc says [1] that format is:
attribute:value;attribute:subattribute=subvalue,subattribute=subvalue;

Does it implicitly mean that in case of several values the following format
is expected (as no subattributes were used): attribute:value1,value2?

[1]
http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/objectattributes

Thank you.
Alexander.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Object attribute format

[Alexander Surkov]

So it'd be good to put the format into the spec. Do I understand correct
that the choice falls at comma separated list?
Thank you.
Alex.


On Fri, May 17, 2013 at 11:44 AM, James Teh ja...@nvaccess.org wrote:

 On 17/05/2013 11:54 AM, Pete Brunet wrote:

 attribute:value1,value2 seems acceptable.

 Agreed.


  Does it implicitly mean that in case of several values the following
 format is expected (as no subattributes were used):
 attribute:value1,value2?

 While the format makes sense, I don't think it's implicit. It isn't
 something I considered while writing NVDA's IA2 attributes parser, so it
 won't handle this without changes. It's probably reasonable that others may
 not have considered it either.

 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372

 __**_
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.**linuxfoundation.orgAccessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.**org/mailman/listinfo/**accessibility-ia2https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Please review the v1.3 update on the IA2 site

[Alexander Surkov]

Hi, Pete. Thanks for finishing it! Do I understand right that link for
downloading IDLs is
http://accessibility.linuxfoundation.org/a11yspecs/ia2/ia2-api-20130501.zip.
Thank you.
Alex.


On Thu, May 16, 2013 at 2:10 PM, Pete Brunet p...@a11ysoft.com wrote:

  The IA2 site has been updated to fix a few things people noticed were
 wrong.  Please take a look and let me know if you find anything that needs
 fixing.

 The top level is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/

 Please ignore the prior zip, ia2-api-20130314.zip.  It will eventually
 disappear.

 The spec is here:
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/

 Pete
 --
 *Pete Brunet*

  a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IAccessibleText::getTextAtOffset for word boundary clarification needed

[Alexander Surkov]

Hi, Pete.

If the string consists of spaces then ATK get word at offset will contain
the word after to the offset if the offset is not inside a word. In this
case there are no words so I think (0, 0, ) triple is returned. However
ATK is not really clear (see for example
http://asurkov.blogspot.ru/2013/04/atx-text-pitfalls.html) to state it
certainly.

 Returns the substring of the specified text type at the specified
 offset.  Refer to IA2TextBoundaryType for more details.

I'd changed that to Returns the substring defined by specified text type
at the specified offset. Refer ..., otherwise it makes me think that
word should be returned in case of word type when offset is outside the
word.

 For the word boundary type if the offset is not at the beginning or
 inside a word the returned string will contain the word before the
 offset.

Offset at the beginning a word is also an offset inside a word. But
actually I like ATK wording:
The returned string will contain the word at the offset if the offset is
inside a word and will contain the word before the offset if the offset is
not inside a word.

  2) If the given offset is a word start then Ctrl+left arrow and Ctrl +
  right arrow return a previous word. Should an order be opposite
  instead since it contradicts to getTextAtOffset semantic?

 I didn't follow that, e.g. why should ctrl+rightArrow move to the
 previous word, but hopefully the above rewording will address your issue.

Yes, it address.

Say the caret is right before 'w' in Hello world. If you press
ctrlLeft+sfhitCtrlRight then you select Hello . If you do an opposite
thing ctrlRight + shiftCtrlLeft then you select world. So the order
makes a difference. Getting back to the spec the world is wanted however
the spec says to return Hello .

Thank you.
Alex.


On Sat, Apr 27, 2013 at 2:12 AM, Pete Brunet p...@a11ysoft.com wrote:


 On 4/16/13 1:29 AM, Alexander Surkov wrote:
  Hi. There are couple issues with IAccessibleText spec.
 
  1) IAccessibleText::getTextAtOffset interface wording is a bit
  confusing [1], it says:
 
  If the index is valid, but no suitable word (or other text type) is
  found, a NULL pointer is returned.
 
  This makes me think (presumably makes me think wrong) that if the
  offset is outside the word then there's no suitable world. However the
  boundary types part says [2]:
 
  The range provided matches the range observed when the application
  processes the Ctrl + left arrow and Ctrl + right arrow key sequences.
  Typically this is from the start of one word to the start of the next.
 
  It means the previous word should be returned.
 
  Notes:
 
  a) A word start boundary from ATK (an analogy to IA2 word boundary)
  says to return previous word as well [3]:
 
   will contain the word before the offset if the offset is not inside
  a word.
 
  b) Firefox returns previous word in this case too.
 
 Hi Alex, What does ATK do when the text area is full of spaces and no
 other text?  That seems like the case where S_FALSE and NULL would be
 returned (except in the case of IA2_TEXT_BOUNDARY_CHAR/ALL).

 How about this rewording?

 Returns the substring of the specified text type at the specified
 offset.  Refer to IA2TextBoundaryType for more details.

 For the word boundary type if the offset is not at the beginning or
 inside a word the returned string will contain the word before the
 offset.  Boundary types of sentence and paragraph should exhibit similar
 behavior.

 If the index is valid, but no suitable text for the specified boundary
 type is found, a NULL pointer is returned.  This would only happen for
 boundary types of word, sentence, and paragraph when the text only
 consists of spaces.
 
 
  2) If the given offset is a word start then Ctrl+left arrow and Ctrl +
  right arrow return a previous word. Should an order be opposite
  instead since it contradicts to getTextAtOffset semantic?
 
 I didn't follow that, e.g. why should ctrl+rightArrow move to the
 previous word, but hopefully the above rewording will address your issue.
 
  ATK says to return this word (i.e. the offset it belongs to), Firefox
  does it in ATKish way.
 
 
  [1]
 
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827
 
  [2]
 
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_text_8idl.html#ad3da05c9bed9f44b1e52eb4adb2924f6
 
  [3]
 
 https://developer.gnome.org/atk/stable/AtkText.html#atk-text-get-text-at-offset
 
 
  Thank you.
 
  Alex.
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] IAccessibleText::getTextAtOffset for word boundary clarification needed

[Alexander Surkov]

Hi. There are couple issues with IAccessibleText spec.

1) IAccessibleText::getTextAtOffset interface wording is a bit confusing
[1], it says:

If the index is valid, but no suitable word (or other text type) is found,
a NULL pointer is returned.

This makes me think (presumably makes me think wrong) that if the offset is
outside the word then there's no suitable world. However the boundary types
part says [2]:

The range provided matches the range observed when the application
processes the Ctrl + left arrow and Ctrl + right arrow key sequences.
Typically this is from the start of one word to the start of the next.

It means the previous word should be returned.

Notes:

a) A word start boundary from ATK (an analogy to IA2 word boundary) says to
return previous word as well [3]:

 will contain the word before the offset if the offset is not inside a
word.

b) Firefox returns previous word in this case too.


2) If the given offset is a word start then Ctrl+left arrow and Ctrl +
right arrow return a previous word. Should an order be opposite instead
since it contradicts to getTextAtOffset semantic?

ATK says to return this word (i.e. the offset it belongs to), Firefox does
it in ATKish way.


[1]
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827

[2]
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_text_8idl.html#ad3da05c9bed9f44b1e52eb4adb2924f6

[3]
https://developer.gnome.org/atk/stable/AtkText.html#atk-text-get-text-at-offset


Thank you.

Alex.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Great news! Pete and all, thank you for the work!
Thank you.
Alex.


On Tue, Apr 16, 2013 at 6:15 AM, Pete Brunet p...@a11ysoft.com wrote:

  The new version is now on the LF site at
 http://accessibility.linuxfoundation.org/a11yspecs/ia2/.  I found a
 couple of minor errors which I will fix soon.  The proxy DLL hasn't been
 verified yet.

 Pete


 On 4/9/13 10:32 AM, Pete Brunet wrote:

 I opened a ticket with the LF admins to archive the 1.2.1 files and add
 the 1.3 files.  I hope someone can verify the new IA2 proxy.  For now
 it's at:http://a11ysoft.com/ia2/proxy-dll/

 Pete

 On 3/15/13 10:58 AM, Alexander Surkov wrote:

  Hopefully Jamie could help with that. I'd be great to have it early Q2.
 Alex.

 On Sat, Mar 16, 2013 at 12:43 AM, Pete Brunet p...@a11ysoft.com 
 p...@a11ysoft.com wrote:

  On 3/14/13 11:03 PM, Alexander Surkov wrote:

 I'm fine with that. I would say As a performant alternative or
 something similar.

 Btw, Pete, what is a plan about releasing?

 I can have these files moved onto the Linux Foundation site at any point now
 (after I make the fix we are talking about).  I would like at least one
 person to try the proxy dll before I do.  Is there a date you are looking at
 for getting this done?


 Alex.


 On Fri, Mar 15, 2013 at 12:40 PM, Pete Brunet p...@a11ysoft.com 
 p...@a11ysoft.com wrote:

 On 3/14/13 9:30 PM, Alexander Surkov wrote:

 Hi, Pete.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 I bet this method is in use in accProbe and aViewer already and it
 must be pretty handy for them. If next IAccessible2 introduces more
 relation types then tools developers don't need to change their code,
 release new version, etc. On the another hand relation type is a
 string so technically the server can implement non standard relations.
 The method to get all of them is quite useful in this case.

 Are there any objections to removing the deprecate tag on IA2::nRelations,
 relation, relations and adding a note to the relations method saying: As an
 alternative, client code should consider using IA2_2::relationTargetsOfType?


 Thank you.
 Alex.


 On Fri, Mar 15, 2013 at 9:57 AM, Pete Brunet p...@a11ysoft.com 
 p...@a11ysoft.com wrote:

 Hi Alex,

 On 3/4/13 10:29 PM, Alexander Surkov wrote:

 Hi, Pete. More feedback.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 2) IAccessible2_2::accessibleWithCaret: Returns the hypertext
 accessible in the subtree of this object, and the caret offset within
 it. It doesn't say which object is returned. In my understanding it
 should be the deepest one.

 I changed that to: Returns the deepest hypertext accessible...  Hopefully
 Arnstein will comment if this is not correct.

 3) Honestly I failed to understand IA2Actions
 (http://a11ysoft.com/ia2/docs/html/_accessible_action_8idl.html), it
 seems referred methods like textAtOffset
 (http://a11ysoft.com/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827)
 say nothing about IA2Action support. I'd be great to provide an
 example how it works. Otherwise it sounds too generic.

 I'm glad you noticed this.  The preamble text is wrong.  I copied it from
 IA2TextBoundaryType as a prototype and didn't finish the work.  These are
 the actions we defined for adding support for HTML5 media.  I changed the
 preamble text to:

 /** This enum defines values which are predefined actions for use when
 implementing
  support for media.

  This enum is used when specifying an action for
 IAccessibleAction::doAction.
 */

 4) changelog (http://a11ysoft.com/ia2/changelog.txt) lists
 IA2_RELATION_GROUPING_OBJECT_FOR, IA2_RELATION_POPUP_INITIATOR_FOR
 relations, however they aren't listed in 
 interfacehttp://a11ysoft.com/ia2/docs/html/_accessible_relation_8idl.html

 Fixed.

 5) IA2_RELATION_CONTAINING_DOCUMENT: makes sense to mention that
 returned object implements IAccessibleDocument interface.

 I added: The target object implements the IAccessibleDocument interface.

 Otherwise it looks good.

 Thanks Alex, I refreshed the IA2 files

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl

 Did anyone try the new proxy?
   http

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Hopefully Jamie could help with that. I'd be great to have it early Q2.
Alex.

On Sat, Mar 16, 2013 at 12:43 AM, Pete Brunet p...@a11ysoft.com wrote:

 On 3/14/13 11:03 PM, Alexander Surkov wrote:

 I'm fine with that. I would say As a performant alternative or
 something similar.

 Btw, Pete, what is a plan about releasing?

 I can have these files moved onto the Linux Foundation site at any point now
 (after I make the fix we are talking about).  I would like at least one
 person to try the proxy dll before I do.  Is there a date you are looking at
 for getting this done?


 Alex.


 On Fri, Mar 15, 2013 at 12:40 PM, Pete Brunet p...@a11ysoft.com wrote:

 On 3/14/13 9:30 PM, Alexander Surkov wrote:

 Hi, Pete.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 I bet this method is in use in accProbe and aViewer already and it
 must be pretty handy for them. If next IAccessible2 introduces more
 relation types then tools developers don't need to change their code,
 release new version, etc. On the another hand relation type is a
 string so technically the server can implement non standard relations.
 The method to get all of them is quite useful in this case.

 Are there any objections to removing the deprecate tag on IA2::nRelations,
 relation, relations and adding a note to the relations method saying: As an
 alternative, client code should consider using IA2_2::relationTargetsOfType?


 Thank you.
 Alex.


 On Fri, Mar 15, 2013 at 9:57 AM, Pete Brunet p...@a11ysoft.com wrote:

 Hi Alex,

 On 3/4/13 10:29 PM, Alexander Surkov wrote:

 Hi, Pete. More feedback.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 2) IAccessible2_2::accessibleWithCaret: Returns the hypertext
 accessible in the subtree of this object, and the caret offset within
 it. It doesn't say which object is returned. In my understanding it
 should be the deepest one.

 I changed that to: Returns the deepest hypertext accessible...  Hopefully
 Arnstein will comment if this is not correct.

 3) Honestly I failed to understand IA2Actions
 (http://a11ysoft.com/ia2/docs/html/_accessible_action_8idl.html), it
 seems referred methods like textAtOffset
 (http://a11ysoft.com/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827)
 say nothing about IA2Action support. I'd be great to provide an
 example how it works. Otherwise it sounds too generic.

 I'm glad you noticed this.  The preamble text is wrong.  I copied it from
 IA2TextBoundaryType as a prototype and didn't finish the work.  These are
 the actions we defined for adding support for HTML5 media.  I changed the
 preamble text to:

 /** This enum defines values which are predefined actions for use when
 implementing
  support for media.

  This enum is used when specifying an action for
 IAccessibleAction::doAction.
 */

 4) changelog (http://a11ysoft.com/ia2/changelog.txt) lists
 IA2_RELATION_GROUPING_OBJECT_FOR, IA2_RELATION_POPUP_INITIATOR_FOR
 relations, however they aren't listed in interface
 http://a11ysoft.com/ia2/docs/html/_accessible_relation_8idl.html

 Fixed.

 5) IA2_RELATION_CONTAINING_DOCUMENT: makes sense to mention that
 returned object implements IAccessibleDocument interface.

 I added: The target object implements the IAccessibleDocument interface.

 Otherwise it looks good.

 Thanks Alex, I refreshed the IA2 files

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl

 Did anyone try the new proxy?
   http://a11ysoft.com/ia2/proxy-dll/


 Thank you.
 Alex.


 On Tue, Mar 5, 2013 at 6:34 AM, Pete Brunet p...@a11ysoft.com wrote:

 Please review the following.  This should be the final unless updates are
 needed.

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl
 - The proxy: http://a11ysoft.com/ia2/proxy-dll/

 Pete

 On 2/26/13 12:30 AM, Pete Brunet wrote:

 If don't hear anything over the next couple of days, I'll assume this won't
 be in 1.3 and I'll finish up the work I need to do to republish the spec on
 a11ysoft.com for one

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Hi, Pete.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

I bet this method is in use in accProbe and aViewer already and it
must be pretty handy for them. If next IAccessible2 introduces more
relation types then tools developers don't need to change their code,
release new version, etc. On the another hand relation type is a
string so technically the server can implement non standard relations.
The method to get all of them is quite useful in this case.

Thank you.
Alex.


On Fri, Mar 15, 2013 at 9:57 AM, Pete Brunet p...@a11ysoft.com wrote:
 Hi Alex,

 On 3/4/13 10:29 PM, Alexander Surkov wrote:

 Hi, Pete. More feedback.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 2) IAccessible2_2::accessibleWithCaret: Returns the hypertext
 accessible in the subtree of this object, and the caret offset within
 it. It doesn't say which object is returned. In my understanding it
 should be the deepest one.

 I changed that to: Returns the deepest hypertext accessible...  Hopefully
 Arnstein will comment if this is not correct.

 3) Honestly I failed to understand IA2Actions
 (http://a11ysoft.com/ia2/docs/html/_accessible_action_8idl.html), it
 seems referred methods like textAtOffset
 (http://a11ysoft.com/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827)
 say nothing about IA2Action support. I'd be great to provide an
 example how it works. Otherwise it sounds too generic.

 I'm glad you noticed this.  The preamble text is wrong.  I copied it from
 IA2TextBoundaryType as a prototype and didn't finish the work.  These are
 the actions we defined for adding support for HTML5 media.  I changed the
 preamble text to:

 /** This enum defines values which are predefined actions for use when
 implementing
  support for media.

  This enum is used when specifying an action for
 IAccessibleAction::doAction.
 */

 4) changelog (http://a11ysoft.com/ia2/changelog.txt) lists
 IA2_RELATION_GROUPING_OBJECT_FOR, IA2_RELATION_POPUP_INITIATOR_FOR
 relations, however they aren't listed in interface
 http://a11ysoft.com/ia2/docs/html/_accessible_relation_8idl.html

 Fixed.

 5) IA2_RELATION_CONTAINING_DOCUMENT: makes sense to mention that
 returned object implements IAccessibleDocument interface.

 I added: The target object implements the IAccessibleDocument interface.

 Otherwise it looks good.

 Thanks Alex, I refreshed the IA2 files

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl

 Did anyone try the new proxy?
   http://a11ysoft.com/ia2/proxy-dll/


 Thank you.
 Alex.


 On Tue, Mar 5, 2013 at 6:34 AM, Pete Brunet p...@a11ysoft.com wrote:

 Please review the following.  This should be the final unless updates are
 needed.

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl
 - The proxy: http://a11ysoft.com/ia2/proxy-dll/

 Pete

 On 2/26/13 12:30 AM, Pete Brunet wrote:

 If don't hear anything over the next couple of days, I'll assume this won't
 be in 1.3 and I'll finish up the work I need to do to republish the spec on
 a11ysoft.com for one more look at it before I get in touch with the Linux
 Foundation IT guys to get it published there.

 On 2/25/13 11:58 PM, Alexander Surkov wrote:

 Probably we should let IA2 1.3 go without addressing this issue. In
 Firefox we still can use IA2 to expose it in non-standard way (like
 new object attribute).
 Alex.


 On Tue, Feb 26, 2013 at 2:49 PM, James Teh ja...@nvaccess.org wrote:

 On 26/02/2013 4:12 PM, Pete Brunet wrote:

 So Is the following what you want?  It moves the method from
 IA2_2 to IAText2 thus resolving an issue for Jamie.
 HRESULT IAccessibleText2::offsetOfChildText (
[in] IUnknown* child,
[out] long* offset
 );

 ...

S_OK is returned if the parent accessible implements IAccessibleText.
S_FALSE is returned if the parent accessible does not implement
 IAccessibleText; [out] value is -1.

 This text needs to be changed for the new method.

 That said, this certainly does look nicer to me. I

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

I'm fine with that. I would say As a performant alternative or
something similar.

Btw, Pete, what is a plan about releasing?

Alex.


On Fri, Mar 15, 2013 at 12:40 PM, Pete Brunet p...@a11ysoft.com wrote:

 On 3/14/13 9:30 PM, Alexander Surkov wrote:

 Hi, Pete.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 I bet this method is in use in accProbe and aViewer already and it
 must be pretty handy for them. If next IAccessible2 introduces more
 relation types then tools developers don't need to change their code,
 release new version, etc. On the another hand relation type is a
 string so technically the server can implement non standard relations.
 The method to get all of them is quite useful in this case.

 Are there any objections to removing the deprecate tag on IA2::nRelations,
 relation, relations and adding a note to the relations method saying: As an
 alternative, client code should consider using IA2_2::relationTargetsOfType?


 Thank you.
 Alex.


 On Fri, Mar 15, 2013 at 9:57 AM, Pete Brunet p...@a11ysoft.com wrote:

 Hi Alex,

 On 3/4/13 10:29 PM, Alexander Surkov wrote:

 Hi, Pete. More feedback.

 1) It makes sense to not deprecate IAccessible2::relations since it
 can be useful for AT tools. In this case maxRelations argument is not
 really needed and it can be marked as ignored but it's not big deal.

 Is there a reason to not deprecate it, i.e. do we need implementers to spend
 the time on it?  What can be done with it that can't be done with
 IA2_2:relationTargetsOfType?

 2) IAccessible2_2::accessibleWithCaret: Returns the hypertext
 accessible in the subtree of this object, and the caret offset within
 it. It doesn't say which object is returned. In my understanding it
 should be the deepest one.

 I changed that to: Returns the deepest hypertext accessible...  Hopefully
 Arnstein will comment if this is not correct.

 3) Honestly I failed to understand IA2Actions
 (http://a11ysoft.com/ia2/docs/html/_accessible_action_8idl.html), it
 seems referred methods like textAtOffset
 (http://a11ysoft.com/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827)
 say nothing about IA2Action support. I'd be great to provide an
 example how it works. Otherwise it sounds too generic.

 I'm glad you noticed this.  The preamble text is wrong.  I copied it from
 IA2TextBoundaryType as a prototype and didn't finish the work.  These are
 the actions we defined for adding support for HTML5 media.  I changed the
 preamble text to:

 /** This enum defines values which are predefined actions for use when
 implementing
  support for media.

  This enum is used when specifying an action for
 IAccessibleAction::doAction.
 */

 4) changelog (http://a11ysoft.com/ia2/changelog.txt) lists
 IA2_RELATION_GROUPING_OBJECT_FOR, IA2_RELATION_POPUP_INITIATOR_FOR
 relations, however they aren't listed in interface
 http://a11ysoft.com/ia2/docs/html/_accessible_relation_8idl.html

 Fixed.

 5) IA2_RELATION_CONTAINING_DOCUMENT: makes sense to mention that
 returned object implements IAccessibleDocument interface.

 I added: The target object implements the IAccessibleDocument interface.

 Otherwise it looks good.

 Thanks Alex, I refreshed the IA2 files

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl

 Did anyone try the new proxy?
   http://a11ysoft.com/ia2/proxy-dll/


 Thank you.
 Alex.


 On Tue, Mar 5, 2013 at 6:34 AM, Pete Brunet p...@a11ysoft.com wrote:

 Please review the following.  This should be the final unless updates are
 needed.

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl
 - The proxy: http://a11ysoft.com/ia2/proxy-dll/

 Pete

 On 2/26/13 12:30 AM, Pete Brunet wrote:

 If don't hear anything over the next couple of days, I'll assume this won't
 be in 1.3 and I'll finish up the work I need to do to republish the spec on
 a11ysoft.com for one more look at it before I get in touch with the Linux
 Foundation IT guys to get it published there.

 On 2/25/13 11:58 PM, Alexander Surkov wrote:

 Probably we should let IA2 1.3 go without addressing this issue. In
 Firefox we still can use IA2 to expose it in non-standard way (like
 new object attribute).
 Alex.


 On Tue, Feb 26, 2013 at 2:49 PM, James Teh ja...@nvaccess.org wrote:

 On 26/02/2013 4:12 PM, Pete Brunet wrote:

 So Is the following

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Hi, Pete. More feedback.

1) It makes sense to not deprecate IAccessible2::relations since it
can be useful for AT tools. In this case maxRelations argument is not
really needed and it can be marked as ignored but it's not big deal.
2) IAccessible2_2::accessibleWithCaret: Returns the hypertext
accessible in the subtree of this object, and the caret offset within
it. It doesn't say which object is returned. In my understanding it
should be the deepest one.
3) Honestly I failed to understand IA2Actions
(http://a11ysoft.com/ia2/docs/html/_accessible_action_8idl.html), it
seems referred methods like textAtOffset
(http://a11ysoft.com/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827)
say nothing about IA2Action support. I'd be great to provide an
example how it works. Otherwise it sounds too generic.
4) changelog (http://a11ysoft.com/ia2/changelog.txt) lists
IA2_RELATION_GROUPING_OBJECT_FOR, IA2_RELATION_POPUP_INITIATOR_FOR
relations, however they aren't listed in interface
http://a11ysoft.com/ia2/docs/html/_accessible_relation_8idl.html
5) IA2_RELATION_CONTAINING_DOCUMENT: makes sense to mention that
returned object implements IAccessibleDocument interface.

Otherwise it looks good.

Thank you.
Alex.


On Tue, Mar 5, 2013 at 6:34 AM, Pete Brunet p...@a11ysoft.com wrote:
 Please review the following.  This should be the final unless updates are
 needed.

 - The change log: http://a11ysoft.com/ia2/changelog.txt
 - IA2 spec: http://a11ysoft.com/ia2/docs/html/
 - The individual IDL files: http://a11ysoft.com/ia2/api/
   or the full IDL file: http://a11ysoft.com/ia2/ia2_api_all.idl
 - The proxy: http://a11ysoft.com/ia2/proxy-dll/

 Pete

 On 2/26/13 12:30 AM, Pete Brunet wrote:

 If don't hear anything over the next couple of days, I'll assume this won't
 be in 1.3 and I'll finish up the work I need to do to republish the spec on
 a11ysoft.com for one more look at it before I get in touch with the Linux
 Foundation IT guys to get it published there.

 On 2/25/13 11:58 PM, Alexander Surkov wrote:

 Probably we should let IA2 1.3 go without addressing this issue. In
 Firefox we still can use IA2 to expose it in non-standard way (like
 new object attribute).
 Alex.


 On Tue, Feb 26, 2013 at 2:49 PM, James Teh ja...@nvaccess.org wrote:

 On 26/02/2013 4:12 PM, Pete Brunet wrote:

 So Is the following what you want?  It moves the method from
 IA2_2 to IAText2 thus resolving an issue for Jamie.
 HRESULT IAccessibleText2::offsetOfChildText (
[in] IUnknown* child,
[out] long* offset
 );

 ...

S_OK is returned if the parent accessible implements IAccessibleText.
S_FALSE is returned if the parent accessible does not implement
 IAccessibleText; [out] value is -1.

 This text needs to be changed for the new method.

 That said, this certainly does look nicer to me. I still think it's a bit of
 a hack, especially given that IAccessibleHyper* should really cover this,
 but at least it's an isolated hack.


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 Pete Brunet

 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G


 --
 Pete Brunet

 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

I'm fine with 1nd option.
Alex.


On Tue, Feb 26, 2013 at 6:20 AM, Pete Brunet p...@a11ysoft.com wrote:
 Alex, Brett, Jamie, What do you recommend?

 1) HRESULT IAccessible2_2::offsetInParentText (
 [out] long* offset
   );

 Return the text offset in the immediate parent node.

 2) Do not add this method.

 3) Something else.

 Pete


 On 2/10/13 8:15 PM, Alexander Surkov wrote:

 It's a total hack. However, imo, this whole idea is a hack. :)

 It could be. IAccessibleHyperlink or IAccessibleText on text leafs are
 hacks and actually it is a thin ice for Firefox. This easily could
 face us to lot of work. Also these approaches aren't really subject of
 the spec and it should introduce even bigger difference in
 implementations between servers.

 On the another hand we have the method on internal layer in Firefox
 that Brett needs. The method is used to build
 IAccessibleText/Hypertext implementation from accessible tree. So if
 AT works both with accessible tree and IAccesisbleText/HyperText for
 text stuff then this method can be useful.

 Thank you.
 Alex.


 On Mon, Feb 11, 2013 at 11:00 AM, James Teh ja...@nvaccess.org wrote:

 On 11/02/2013 11:22 AM, Alexander Surkov wrote:

 Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
 IAccessibleHyperlink was implemented by embedded objects only then
 this might be something that AT relies on.

 I guess this is a possibility, though I'd assume that ATs that don't need
 text leaf nodes wouldn't traverse them. We'd certainly need ot check,
 though.


 On the another hand parent
 IAccessibleHyperText would return a collection of children instead the
 collection of embedded objects and AT could have dependencies on it as
 well.

 Ah. I was imagining that the parent IAccessibleHypertext wouldn't return the
 text leaf nodes. See notes on hack below.


 pure IAccessibleHyperlink on text leafs
 is rather a hack than it suites them well.

 It's a total hack. However, imo, this whole idea is a hack. :)


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 Pete Brunet

 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

I don't mind adding the method to the spec but I don't have strong
opinion either. I agree with Jamie that keeping the text method on
IAccessible2 looks unusual. In Gecko we keep an analogue method in
text interface:
int32_t GetChildOffset(Accessible* aChild);

Alex.


On Tue, Feb 26, 2013 at 12:29 PM, James Teh ja...@nvaccess.org wrote:
 Unusually :), I find it difficult to give an opinion on this. Clearly,
 multiple people think it should be introduced. However, I find it very hard
 to justify introducing what is essentially a hack into the main IAccessible2
 interface. Furthermore, this method is related to IAccessibleText, yet it's
 not in a text specific interface. Once it's in the main interface, it can't
 be removed and server implementers have to implement it, even if they just
 throw not implemented. If it must be introduced, I'd prefer to see a
 separate interface for it, but that seems rather silly. In short, I'm not
 going to fight inclusion of this, since I don't have strong enough arguments
 against, but I'm not entirely comfortable with it either.

 Jamie


 On 26/02/2013 7:50 AM, Pete Brunet wrote:

 Alex, Brett, Jamie, What do you recommend?

 1) HRESULT IAccessible2_2::offsetInParentText (
  [out] long* offset
);

 Return the text offset in the immediate parent node.

 2) Do not add this method.

 3) Something else.

 Pete

 On 2/10/13 8:15 PM, Alexander Surkov wrote:

 It's a total hack. However, imo, this whole idea is a hack. :)

 It could be. IAccessibleHyperlink or IAccessibleText on text leafs are
 hacks and actually it is a thin ice for Firefox. This easily could
 face us to lot of work. Also these approaches aren't really subject of
 the spec and it should introduce even bigger difference in
 implementations between servers.

 On the another hand we have the method on internal layer in Firefox
 that Brett needs. The method is used to build
 IAccessibleText/Hypertext implementation from accessible tree. So if
 AT works both with accessible tree and IAccesisbleText/HyperText for
 text stuff then this method can be useful.

 Thank you.
 Alex.


 On Mon, Feb 11, 2013 at 11:00 AM, James Tehja...@nvaccess.org  wrote:

 On 11/02/2013 11:22 AM, Alexander Surkov wrote:

 Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
 IAccessibleHyperlink was implemented by embedded objects only then
 this might be something that AT relies on.

 I guess this is a possibility, though I'd assume that ATs that don't
 need
 text leaf nodes wouldn't traverse them. We'd certainly need ot check,
 though.


 On the another hand parent
 IAccessibleHyperText would return a collection of children instead the
 collection of embedded objects and AT could have dependencies on it as
 well.

 Ah. I was imagining that the parent IAccessibleHypertext wouldn't return
 the
 text leaf nodes. See notes on hack below.


 pure IAccessibleHyperlink on text leafs
 is rather a hack than it suites them well.

 It's a total hack. However, imo, this whole idea is a hack. :)


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email:ja...@nvaccess.org
 Web site:http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 *Pete Brunet*


 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G


 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Hi, Pete.

It shouldn't be static. The object is method called on is a parent.

HRESULT IAccessibleText2::childOffset (
   [in] IUnknown* childAccessible,
   [out] long* offset
);

 Also, what interfaces are implemented on the child nodes?

depending on the object. These are IAccessible/IAccessible2,
IAccessibleImage in case of image.

 BTW, not being in the situation of needing this for my own implementation
 I'm trusting our implementers to convey whether or not this is generally
 useful to the IA2 community.  If not then we shouldn't add the method
 especially since there is the solution of the private interface.

Yes, I think we can always invent on own. For example, VARIANT object
attributes from 1.3 should work here. Probably that's the way to go
since we can't reach an agreement on this item.

Thank you.
Alex.


On Tue, Feb 26, 2013 at 1:32 PM, Pete Brunet p...@a11ysoft.com wrote:

 On 2/25/13 9:40 PM, Alexander Surkov wrote:

 I don't mind adding the method to the spec but I don't have strong
 opinion either. I agree with Jamie that keeping the text method on
 IAccessible2 looks unusual. In Gecko we keep an analogue method in
 text interface:
 int32_t GetChildOffset(Accessible* aChild);

 That's a static method.  Is it OK to have static methods in IDL?  If so
 would it make sense to add the following to IAText2?

 =
 HRESULT IAccessibleText2::offsetInParent (
   [in] IUnknown* accessible,
   [out] long* offset
);

 Return the text offset in the parent of the specified accessible.

 Return the text offset in the parent of the specified accessible
 corresponding to the beginning of the text associated with the specified
 accessible.

 Returns:
   S_OK is returned if the parent accessible implements IAccessibleText.
   S_FALSE is returned if the parent accessible does not implement
 IAccessibleText; [out] value is -1.

 Note: This is a static method.
 =

 Also, what interfaces are implemented on the child nodes?

 BTW, not being in the situation of needing this for my own implementation
 I'm trusting our implementers to convey whether or not this is generally
 useful to the IA2 community.  If not then we shouldn't add the method
 especially since there is the solution of the private interface.



 Alex.


 On Tue, Feb 26, 2013 at 12:29 PM, James Teh ja...@nvaccess.org wrote:

 Unusually :), I find it difficult to give an opinion on this. Clearly,
 multiple people think it should be introduced. However, I find it very hard
 to justify introducing what is essentially a hack into the main IAccessible2
 interface. Furthermore, this method is related to IAccessibleText, yet it's
 not in a text specific interface. Once it's in the main interface, it can't
 be removed and server implementers have to implement it, even if they just
 throw not implemented. If it must be introduced, I'd prefer to see a
 separate interface for it, but that seems rather silly.

 We do have a precedent in IADocument::anchorText.  That's the only method in
 that interface.

 In short, I'm not
 going to fight inclusion of this, since I don't have strong enough arguments
 against, but I'm not entirely comfortable with it either.

 Jamie


 On 26/02/2013 7:50 AM, Pete Brunet wrote:

 Alex, Brett, Jamie, What do you recommend?

 1) HRESULT IAccessible2_2::offsetInParentText (
  [out] long* offset
);

 Return the text offset in the immediate parent node.

 2) Do not add this method.

 3) Something else.

 Pete

 On 2/10/13 8:15 PM, Alexander Surkov wrote:

 It's a total hack. However, imo, this whole idea is a hack. :)

 It could be. IAccessibleHyperlink or IAccessibleText on text leafs are
 hacks and actually it is a thin ice for Firefox. This easily could
 face us to lot of work. Also these approaches aren't really subject of
 the spec and it should introduce even bigger difference in
 implementations between servers.

 On the another hand we have the method on internal layer in Firefox
 that Brett needs. The method is used to build
 IAccessibleText/Hypertext implementation from accessible tree. So if
 AT works both with accessible tree and IAccesisbleText/HyperText for
 text stuff then this method can be useful.

 Thank you.
 Alex.


 On Mon, Feb 11, 2013 at 11:00 AM, James Tehja...@nvaccess.org  wrote:

 On 11/02/2013 11:22 AM, Alexander Surkov wrote:

 Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
 IAccessibleHyperlink was implemented by embedded objects only then
 this might be something that AT relies on.

 I guess this is a possibility, though I'd assume that ATs that don't
 need
 text leaf nodes wouldn't traverse them. We'd certainly need ot check,
 though.


 On the another hand parent
 IAccessibleHyperText would return a collection of children instead the
 collection of embedded objects and AT could have dependencies on it as
 well.

 Ah. I was imagining that the parent IAccessibleHypertext wouldn't return
 the
 text leaf nodes. See notes on hack below.


 pure

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Probably we should let IA2 1.3 go without addressing this issue. In
Firefox we still can use IA2 to expose it in non-standard way (like
new object attribute).
Alex.


On Tue, Feb 26, 2013 at 2:49 PM, James Teh ja...@nvaccess.org wrote:
 On 26/02/2013 4:12 PM, Pete Brunet wrote:

 So Is the following what you want?  It moves the method from
 IA2_2 to IAText2 thus resolving an issue for Jamie.
 HRESULT IAccessibleText2::offsetOfChildText (
[in] IUnknown* child,
[out] long* offset
 );

 ...

S_OK is returned if the parent accessible implements IAccessibleText.
S_FALSE is returned if the parent accessible does not implement
 IAccessibleText; [out] value is -1.

 This text needs to be changed for the new method.

 That said, this certainly does look nicer to me. I still think it's a bit of
 a hack, especially given that IAccessibleHyper* should really cover this,
 but at least it's an isolated hack.


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
IAccessibleHyperlink was implemented by embedded objects only then
this might be something that AT relies on. On the another hand parent
IAccessibleHyperText would return a collection of children instead the
collection of embedded objects and AT could have dependencies on it as
well. I even can't guarantee that we don't have any dependencies on
that internally in Firefox :)

It's different but might be a cause too. If text leaf implements
IAccessibleHyperlink then only startIndex and endIndex make sense on
it. All other methods like valid, selected, anchorCount, etc aren't
applicable to text leafs. So pure IAccessibleHyperlink on text leafs
is rather a hack than it suites them well.

Thank you.
Alex.


On Mon, Feb 11, 2013 at 9:03 AM, James Teh ja...@nvaccess.org wrote:
 On 7/02/2013 1:10 PM, Pete Brunet wrote:

 Alex, Do you see any need to restrict this to the immediate parent? I'm
 going to assume not in the following:
 HRESULT IAccessible2_2::offsetInAncestorText (

 I'm not sure it makes sense to do this for ancestors other than the
 immediate parent. As I understand it, the point of this method is to get
 back into the realm of IAccessibleText when the text is mirrored in text
 leaf nodes. If there's an accessible between the text leaf and its
 IAccessibleText object, the in-between accessible could itself consume
 offsets in the text. if it is decided to allow it for ancestors, the method
 should probably also return the relevant ancestor.

 Alex, can you explain why using IAccessibleHyperlink breaks backwards
 compatibility as opposed to adding this new method?


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

 It's a total hack. However, imo, this whole idea is a hack. :)

It could be. IAccessibleHyperlink or IAccessibleText on text leafs are
hacks and actually it is a thin ice for Firefox. This easily could
face us to lot of work. Also these approaches aren't really subject of
the spec and it should introduce even bigger difference in
implementations between servers.

On the another hand we have the method on internal layer in Firefox
that Brett needs. The method is used to build
IAccessibleText/Hypertext implementation from accessible tree. So if
AT works both with accessible tree and IAccesisbleText/HyperText for
text stuff then this method can be useful.

Thank you.
Alex.


On Mon, Feb 11, 2013 at 11:00 AM, James Teh ja...@nvaccess.org wrote:
 On 11/02/2013 11:22 AM, Alexander Surkov wrote:

 Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
 IAccessibleHyperlink was implemented by embedded objects only then
 this might be something that AT relies on.

 I guess this is a possibility, though I'd assume that ATs that don't need
 text leaf nodes wouldn't traverse them. We'd certainly need ot check,
 though.


 On the another hand parent
 IAccessibleHyperText would return a collection of children instead the
 collection of embedded objects and AT could have dependencies on it as
 well.

 Ah. I was imagining that the parent IAccessibleHypertext wouldn't return the
 text leaf nodes. See notes on hack below.


 pure IAccessibleHyperlink on text leafs
 is rather a hack than it suites them well.

 It's a total hack. However, imo, this whole idea is a hack. :)


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Hi, Pete. if a parent accessible implements and if no parent nodes
implementing IAccessibleText are found sounds ambiguously. 1st
assumes an immediate parent, 2nd assumes an accessible from the parent
chain. I'm not sure about other IA2 implementation but in Firefox if
the parent accessible doesn't implement IAccessibleText then this
accessible can't be a text of some other accessible from the parent
chain. In other words only 1st scenario is possible in Firefox.

Thank you.
Alex.


On Thu, Feb 7, 2013 at 11:42 AM, Pete Brunet p...@a11ysoft.com wrote:
 Thanks Alex, How is this?

 HRESULT IAccessible2_2::offsetInParentText (
 [out] long* offset
   );

 Return text offset in parent.

 Determine the parent accessible which implements IAccessibleText and
 return the offset in that object which corresponds to the beginning of
 the text associated with this accessible.

 Returns:
   S_OK is returned if a parent accessible implements
 IAccessibleText.
   S_FALSEis returned if no parent nodes implementing IAccessibleText
 are found; [out] value is -1.

 On 2/6/13 8:02 PM, Alexander Surkov wrote:
 Hi, Pete. The method looks ok. Few notes.

 If this accessible implements IAccessibleText then it can be a child
 of another IAccessibleText, in this case it also has associated text
 (embedded character) and thus it has valid offset. Btw, I would use -1
 in case when there's no parent IAccessibleText instead of 0 since 0 is
 valid offset and it may be confusing (I saw S_FALSE which is
 reasonable but anyway).

 Thank you.
 Alex.


 On Thu, Feb 7, 2013 at 2:43 AM, Pete Brunet p...@a11ysoft.com wrote:
 Since there is a need for this and the solution is easy to implement it
 seems worth adding.  Here is a draft for review.

 HRESULT IAccessible2_2::offsetInParentText (
 [out] long* offset
   );

 Return text offset in parent.

 Determine the parent accessible which implements IAccessibleText and return
 the offset in that object which corresponds to the beginning of the text
 associated with this accessible.  If this accessible implements
 IAccessibleText, 0 will be returned.

 Returns:
   S_OK is returned if this accessible or a parent accessible implements
 IAccessibleText.
   S_FALSE is returned if no nodes implementing IAccessibleText are found;
 [out] value is 0.


 On 2/5/13 10:58 PM, Alexander Surkov wrote:

 Hi, Pete.

 Options were discussed:
 1) make text leaf accessible implement IAccessibleText (I didn't like
 it, see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
 2) make text leaf accessible implement IAccessibleHyperLink (I didn't
 like it, see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
 3) add a new method DescendantOffset(IAccessible* acc, long* offset)
 like Brett suggested (see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html).
 I don't mind. It's easy to implement.
 4) do nothing (Jamie mentioned that pure
 IAccessibleText/HyperLink/HyperText should work also as alternative
 approach to the approach described by Brett, but here we probably run
 into restrictions of proprietary softwares).

 Thank you.
 Alex.


 On Wed, Feb 6, 2013 at 2:31 AM, Pete Brunet p...@a11ysoft.com wrote:

 To all,

 Please review the thread Brett started at:
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html

 to see if any further progress can be made on this issue.


 On 2/5/13 8:46 AM, Brett Lewis wrote:

 Hi,
 I wish we could get it in but it definitely sounded like there was no
 consensus on the issue, so let's let it go.
 Thanks,
 Brett


 
 From: Pete Brunet [mailto:p...@a11ysoft.com]
 Sent: Monday, February 04, 2013 7:02 PM
 To: Brett Lewis
 Cc: IAccessible2 mailing list
 Subject: Re: [Accessibility-ia2] Plea for a new function

 Hi Brett, Is this still an issue for you?  We're very near the end of
 discussions for IA2 1.3 and wanted to see if more discussion is needed on
 this issue.  -Pete

 On 11/26/12 7:03 PM, James Teh wrote:

 On 27/11/2012 8:02 AM, Brett Lewis wrote:

 I am getting the Iaccessible tree.  I then find that I want the text
 attributes for one of my leaf nodes and find that I have to go back up the
 Iaccessible tree to find the nearest Iaccessible node that allow QI to
 IAccessibleText and then trying to figure out how to map the result back
 down to my Iaccessible leaf node.

 If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e.
 pretend they don't exist. That way, you're only dealing with nodes that
 support IAccessibleText. However, there may well be a good reason you can't
 do this.

 Jamie

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Being generic isn't necessary bad. I'm not sure though that an
alternative and unambiguous text interface implementation is possible.
But I'm fine with the method as long as it allows Firefox to return -1
for the accessible having no IAccessibleText immediate parent.

I'd love to hear what Jamie thinks.

Thank you.
Alex.


On Thu, Feb 7, 2013 at 12:10 PM, Pete Brunet p...@a11ysoft.com wrote:
 Alex, Do you see any need to restrict this to the immediate parent?  I'm
 going to assume not in the following:

 HRESULT IAccessible2_2::offsetInAncestorText (
 [out] long* offset
   );

 Return the text offset in an ancestor node.

 Determine the closest ancestor in the tree of accessibles which implements
 IAccessibleText and return the offset in that accessible which corresponds
 to the beginning of the text associated with this accessible.

 Returns:
   S_OK is returned if an ancestor accessible implements IAccessibleText.
   S_FALSE is returned if no ancestor node implementing IAccessibleText are
 found; [out] value is -1.


 On 2/6/13 8:55 PM, Alexander Surkov wrote:

 Hi, Pete. if a parent accessible implements and if no parent nodes
 implementing IAccessibleText are found sounds ambiguously. 1st
 assumes an immediate parent, 2nd assumes an accessible from the parent
 chain. I'm not sure about other IA2 implementation but in Firefox if
 the parent accessible doesn't implement IAccessibleText then this
 accessible can't be a text of some other accessible from the parent
 chain. In other words only 1st scenario is possible in Firefox.

 Thank you.
 Alex.


 On Thu, Feb 7, 2013 at 11:42 AM, Pete Brunet p...@a11ysoft.com wrote:

 Thanks Alex, How is this?

 HRESULT IAccessible2_2::offsetInParentText (
 [out] long* offset
   );

 Return text offset in parent.

 Determine the parent accessible which implements IAccessibleText and
 return the offset in that object which corresponds to the beginning of
 the text associated with this accessible.

 Returns:
   S_OK is returned if a parent accessible implements
 IAccessibleText.
   S_FALSEis returned if no parent nodes implementing IAccessibleText
 are found; [out] value is -1.

 On 2/6/13 8:02 PM, Alexander Surkov wrote:

 Hi, Pete. The method looks ok. Few notes.

 If this accessible implements IAccessibleText then it can be a child
 of another IAccessibleText, in this case it also has associated text
 (embedded character) and thus it has valid offset. Btw, I would use -1
 in case when there's no parent IAccessibleText instead of 0 since 0 is
 valid offset and it may be confusing (I saw S_FALSE which is
 reasonable but anyway).

 Thank you.
 Alex.


 On Thu, Feb 7, 2013 at 2:43 AM, Pete Brunet p...@a11ysoft.com wrote:

 Since there is a need for this and the solution is easy to implement it
 seems worth adding.  Here is a draft for review.

 HRESULT IAccessible2_2::offsetInParentText (
 [out] long* offset
   );

 Return text offset in parent.

 Determine the parent accessible which implements IAccessibleText and return
 the offset in that object which corresponds to the beginning of the text
 associated with this accessible.  If this accessible implements
 IAccessibleText, 0 will be returned.

 Returns:
   S_OK is returned if this accessible or a parent accessible implements
 IAccessibleText.
   S_FALSE is returned if no nodes implementing IAccessibleText are found;
 [out] value is 0.


 On 2/5/13 10:58 PM, Alexander Surkov wrote:

 Hi, Pete.

 Options were discussed:
 1) make text leaf accessible implement IAccessibleText (I didn't like
 it, see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
 2) make text leaf accessible implement IAccessibleHyperLink (I didn't
 like it, see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
 3) add a new method DescendantOffset(IAccessible* acc, long* offset)
 like Brett suggested (see
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html).
 I don't mind. It's easy to implement.
 4) do nothing (Jamie mentioned that pure
 IAccessibleText/HyperLink/HyperText should work also as alternative
 approach to the approach described by Brett, but here we probably run
 into restrictions of proprietary softwares).

 Thank you.
 Alex.


 On Wed, Feb 6, 2013 at 2:31 AM, Pete Brunet p...@a11ysoft.com wrote:

 To all,

 Please review the thread Brett started at:
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html

 to see if any further progress can be made on this issue.


 On 2/5/13 8:46 AM, Brett Lewis wrote:

 Hi,
 I wish we could get it in but it definitely sounded like there was no
 consensus on the issue, so let's let it go.
 Thanks,
 Brett


 
 From: Pete Brunet [mailto:p...@a11ysoft.com]
 Sent: Monday, February 04, 2013 7:02 PM
 To: Brett Lewis
 Cc: IAccessible2 mailing list
 Subject: Re: [Accessibility-ia2] Plea for a new function

 Hi

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Hi, Pete.

Options were discussed:
1) make text leaf accessible implement IAccessibleText (I didn't like
it, see 
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
2) make text leaf accessible implement IAccessibleHyperLink (I didn't
like it, see 
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
3) add a new method DescendantOffset(IAccessible* acc, long* offset)
like Brett suggested (see
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html).
I don't mind. It's easy to implement.
4) do nothing (Jamie mentioned that pure
IAccessibleText/HyperLink/HyperText should work also as alternative
approach to the approach described by Brett, but here we probably run
into restrictions of proprietary softwares).

Thank you.
Alex.


On Wed, Feb 6, 2013 at 2:31 AM, Pete Brunet p...@a11ysoft.com wrote:
 To all,

 Please review the thread Brett started at:
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html

 to see if any further progress can be made on this issue.


 On 2/5/13 8:46 AM, Brett Lewis wrote:

 Hi,
 I wish we could get it in but it definitely sounded like there was no
 consensus on the issue, so let's let it go.
 Thanks,
 Brett


 
 From: Pete Brunet [mailto:p...@a11ysoft.com]
 Sent: Monday, February 04, 2013 7:02 PM
 To: Brett Lewis
 Cc: IAccessible2 mailing list
 Subject: Re: [Accessibility-ia2] Plea for a new function

 Hi Brett, Is this still an issue for you?  We're very near the end of
 discussions for IA2 1.3 and wanted to see if more discussion is needed on
 this issue.  -Pete

 On 11/26/12 7:03 PM, James Teh wrote:

 On 27/11/2012 8:02 AM, Brett Lewis wrote:

 I am getting the Iaccessible tree.  I then find that I want the text
 attributes for one of my leaf nodes and find that I have to go back up the
 Iaccessible tree to find the nearest Iaccessible node that allow QI to
 IAccessibleText and then trying to figure out how to map the result back
 down to my Iaccessible leaf node.

 If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e.
 pretend they don't exist. That way, you're only dealing with nodes that
 support IAccessibleText. However, there may well be a good reason you can't
 do this.

 Jamie


 --
 Pete Brunet

 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G


 --
 Pete Brunet

 a11ysoft - Accessibility Architecture and Development
 (512) 467-4706 (work), (512) 689-4155 (cell)
 Skype: pete.brunet
 IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
 http://www.a11ysoft.com/about/
 Ionosphere: WS4G

 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Hi, Pete. It looks good. Perhaps I'd change In some cases an
application's accessible tree is such that an object can have a
logical parent which is not its parent in the tree of accessibles. to
... such that objects can be in a logical parent-child relationship
which is different from hierarchy in the accessible tree.

Thank you.
Alex.


On Tue, Feb 5, 2013 at 11:46 AM, Pete Brunet p...@a11ysoft.com wrote:

 On 2/4/13 8:16 PM, Alexander Surkov wrote:

 Hi, Pete. Thank you for getting back on this. Answering inline.

 1) It makes sense to allow IAccessible2_2::attribute to take sequence
 of attribute names like margin-left;margin-right; to get these
 attribute values for a single call.

 Is this important enough to add additional development effort for server
 side implementers?

 Let's leave it out of IA2 1.3. Otherwise I afraid we never get it
 done. If the feature is needed by AT then it can be prototyped in the
 browser before we put it into spec since it doesn't require the
 interface changes.

 3) Any specific reason to use long for nTargets in
 relationTargetsOfType since it seems it never takes negative values?

 It's a good point, but since an unsigned long wasn't used anywhere else it
 seems like at least for the sake of consistency to leave it as is.

 I don't mind.

 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
 go with array instead EnumVariant? Do AT want to get all items at once
 even if the document is big and has many links?

 Back on 14 Aug 2012 you agreed that the array would be preferred in order to
 keep it consistent with the array returned by
 IAccessible2_2::relationTargetsOfType.

 If I agreed then ok :) It seems our discussion is many years long. I
 can hardly remember where we started from. I think my point was that
 obtaining all hyperlinks can be slow. If it is an issue then we can
 address it the next round if necessary.

 8) IA2_RELATION_NODE_PARENT_OF This object is a parent of a target
 object. It's not clear as well since it doesn't answer why
 get_accParent doesn't work. Maybe you should say it's a logical parent
 and the relation is reverse to RELATION_NODE_CHILD_OF. It is used, for
 example, for flat structured trees.

 I could remove it.  Noone else showed interest in it other than for symmetry
 with IA2_RELATION_NODE_CHILD_OF.  The comment about get_accParent is a good
 one.  You asked for this new relation back on 9 Nov 09 because you added it
 for ATK and wanted to enhance the symmetry between the ATK and IA2
 interfaces.  Or I could just add another sentence, This relation is the
 reciprocal of IA2_RELATION_NODE_CHILD_OF.  I didn't understand the comment
 about flat structured trees but if you want to keep this relation please
 provide an additional sentence.

 We shouldn't remove it. It's needed for sync with ATK. Also this
 constant was settled down in ARIA spec implementation guide already :)

 If you use logical parent instead parent (i.e. not a parent in the
 accessible tree) then it should be fine. It can sound This object is
 a logical parent of a target object. This relation is the reciprocal
 of IA2_RELATION_NODE_CHILD_OF.

 About flat trees. The accessible tree may look like:

 div role=tree
   div role=treeitem level=1item/div
   div role=treeitem level=2sub item/div
 /div

 in this case parent for 'item' and 'subitem' is 'tree' but logical
 parent of 'subitem' is 'item'.

 I updated the comments as follows.  Please review.

 /** This object is a logical child of a target object.  This relation is the
 reciprocal
  of the IA2_RELATION_NODE_PARENT_OF relation. In some cases an application's
 accessible
  tree is such that an object can have a logical parent which is not its
 parent in the
  tree of accessibles. */
 const WCHAR *const IA2_RELATION_NODE_CHILD_OF = LnodeChildOf;

 /** This object is a logical parent of a target object. This relation is the
 reciprocal
  of the IA2_RELATION_NODE_CHILD_OF relation. In some cases an application's
 accessible
  tree is such that an object can have a logical parent which is not its
 parent in the
  tree of accessibles. */
 const WCHAR *const IA2_RELATION_NODE_PARENT_OF = LnodeParentOf;


 Thank you.
 Alex.


 On Tue, Feb 5, 2013 at 8:13 AM, Pete Brunet p...@a11ysoft.com wrote:

 Hi Alex, I am going to try to get some momentum going on this again...


 On 9/23/12 11:52 PM, Alexander Surkov wrote:

 Hi, Pete. Here's my two cents.

 1) It makes sense to allow IAccessible2_2::attribute to take sequence
 of attribute names like margin-left;margin-right; to get these
 attribute values for a single call.

 Is this important enough to add additional development effort for server
 side implementers?

 2) It'd be nice to add a reference to relation constants for
 relationTargetsOfType method description, see [in] type The requested
 relation type.

 Done.

 3) Any specific reason to use long for nTargets in
 relationTargetsOfType since it seems it never takes negative values?

 It's a good point

Re: [Accessibility-ia2] Plea for a new function

[Alexander Surkov]

Hi, Jamie. I think Brett meant accessible object for text node (aka
text leaf accessible).

In general accessible objects for text nodes aren't really necessary
since they dupe info that is provided by IAccessibleText on the
container. So there's no need for them in IA2 world, they are rather
MSAA heritage. However I has been told that having accessible objects
for text nodes is still useful for AT (I'm not really aware of
details) and that's why we keep them in Firefox btw. This is a reason
why I don't want text nodes to implement IAccessibleText (besides it
won't be trivial to implement).

IAccessibleHyperlink idea might be ok, it's not backward compatible
though and makes nsIAccessibleHyperText nearly useless since it dupes
IAccessbile/IAccessbile2 methods.

Having a new method that returns an offset for a child (and child by
offset?) might be ok.

Thank you.
Alex.


On Wed, Nov 21, 2012 at 9:11 AM, James Teh ja...@nvaccess.org wrote:
 Hi.

 There are two problems here:
 1. It's unclear what is considered the text of a descendant node which
 doesn't support IAccessibleText. It could be accName, accValue,
 accDescription, etc. or some combination thereof.
 2. This assumes that a descendant node's text actually is contained in the
 ancestor IAccessibleText object, which might not be the case. Of course, I
 guess the method could just fail if this weren't the case.

 Also, why not just implement IAccessibleText on the descendant nodes?

 In any case, I don't think a new method is required for this. You can
 implement IAccessibleHyperlink on the descendant nodes. The startIndex and
 endIndex properties of IAccessibleHyperlink should give you what you need.

 Jamie


 On 21/11/2012 9:30 AM, Brett Lewis wrote:

 All:
 I have recently run into a situation for which there presently doesn't
 appear to be a good solution.
 1.  The problem.  I wished to obtain the attributes for the text at a
 particular offset.  This is straightforward using IAccessibleText and
 just asking for the attributes at the offset of interest.  The
 difficulty is that the node whose text attributes I wanted didn't
 support IAccessibleText.  One of its ancestors did and this ancestor did
 contain information about the attributes I needed.  The question
 then became, how can I find out where in a given IAccessibleText string
 does a descendants node text begin.  I haven't found an easy way to
 answer this question.
 2.  Proposed solution:  Add a new function that returns the offset in
 the current IAccessibleText text string for a given IAccessible for a
 descendant. So something like:
 DescendantOffset(IAccessible* acc,VARIANT varChild, long* offset)
 I have no strong preference for exactly how this should be handled, just
 the need for such a function.
 I know the 1.3 version of the IAccessible2 specification is nearly
 ready, but I would like to see if this new function could be included.
 In addition to the attributes for text at a given offset, I have also
 seen a case where we needed the rectangle for particular characters.
 Again, in this instance, we needed to locate the nearest ancestor
 supporting IAccessibleText and try to determine the offset in this
 ancestor of the node of interest.
 What does everyone think about such an addition?
 Any feedback would be much appreciated.
 Thanks,
 Brett Lewis


 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

Hi, Jamie. Answering inline.

 5) Document that copyText, cutText, and pasteText are deprecated.
 Can you please refresh me on it? The reason specified is This
 function is available via the application's GUI. but it seems it can
 be applied to the whole IAccessibleEditableText interface.

 I believe there was some talk a while ago about making these all actions
 which can be triggered using the standard action mechanism. This would
 require a way to perform an action given a constant. It is why the idea of
 using negative action indices came up.

It seems it doesn't answer why we can't turn out the whole
IAccessibleEditableText interface into actions.
Btw, I would prefer doAction taking a BSTR rather than negative
constant. Otherwise we should standardize all possible actions and we
don't leave a room for the server to introduce non-standard actions.

 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
 go with array instead EnumVariant? Do AT want to get all items at once
 even if the document is big and has many links?

It seems we didn't go with EnumVariant at all but we added maxCount
'in' argument. Should we have it here as well?

 7) IA2_RELATION_GROUPING_OBJECT_FOR: This object is a grouping object
 for the target object. - it'd be nice to give a hint for
 implementers. After a time I don't really remember what is it about :)

 I guess a grouping object/container would expose this relation referring to
 all objects it contains. Is this really useful?

It'd be nice to have examples. Does it applicable to HTML fieldset and
HTML form? Should it include the element connected by node_child_of
relation if the element is not a descendant?

Thank you.
Alex.


On Wed, Oct 10, 2012 at 3:39 PM, James Teh ja...@nvaccess.org wrote:
 On 24/09/2012 2:52 PM, Alexander Surkov wrote:

 5) Document that copyText, cutText, and pasteText are deprecated.
 Can you please refresh me on it? The reason specified is This
 function is available via the application's GUI. but it seems it can
 be applied to the whole IAccessibleEditableText interface.

 I believe there was some talk a while ago about making these all actions
 which can be triggered using the standard action mechanism. This would
 require a way to perform an action given a constant. It is why the idea of
 using negative action indices came up.


 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
 go with array instead EnumVariant? Do AT want to get all items at once
 even if the document is big and has many links?

 Isn't that the whole point of this method? Otherwise, wouldn't
 IAccessibleHypertext::hyperlink be enough? Maybe I'm missing something...


 7) IA2_RELATION_GROUPING_OBJECT_FOR: This object is a grouping object
 for the target object. - it'd be nice to give a hint for
 implementers. After a time I don't really remember what is it about :)

 I guess a grouping object/container would expose this relation referring to
 all objects it contains. Is this really useful?


 9)  Description for IA2_RELATION_POPUP_INITIATOR_FOR doesn't make
 things really clear for implementers too.

 Yeah; I have no idea what this is for. :)

 Btw, the used string is
 popInitiatorFor,

 Looks like a typo to me.

 Thanks,
 Jamie


 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Alexander Surkov]

 Btw, I would prefer doAction taking a BSTR rather than negative
 constant. Otherwise we should standardize all possible actions and we
 don't leave a room for the server to introduce non-standard actions.

 This requires a new method (and thus a new interface), which was the main
 reason for avoiding it. However, I'm not really against this.

I see.

 Using strings
 is a touch more expensive, but it's negligible and more extensible.

we can go with VARIANT as we did for object attributes.

Alex.


On Wed, Oct 10, 2012 at 4:24 PM, James Teh ja...@nvaccess.org wrote:
 On 10/10/2012 5:07 PM, Alexander Surkov wrote:

 It seems [introducing actions for editable text operations] doesn't answer
 why we can't turn out the whole
 IAccessibleEditableText interface into actions.

 I agree and tend to think this is the way forward.


 Btw, I would prefer doAction taking a BSTR rather than negative
 constant. Otherwise we should standardize all possible actions and we
 don't leave a room for the server to introduce non-standard actions.

 This requires a new method (and thus a new interface), which was the main
 reason for avoiding it. However, I'm not really against this. Using strings
 is a touch more expensive, but it's negligible and more extensible.


 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
 go with array instead EnumVariant? Do AT want to get all items at once
 even if the document is big and has many links?

 It seems we didn't go with EnumVariant at all but we added maxCount
 'in' argument. Should we have it here as well?

 We could do that. The question is whether an AT is ever going to want to
 retrieve anything other than one or all hyperlinks. I can only come up with
 use cases for one or all.


 Jamie

 --
 James Teh
 Director, NV Access Limited
 Email: ja...@nvaccess.org
 Web site: http://www.nvaccess.org/
 Phone: +61 7 5667 8372
 ___
 Accessibility-ia2 mailing list
 Accessibility-ia2@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2