Re: [Accessibility-ia2] HTML elements mapping

[Alexander Surkov]

On Thu, Jan 4, 2018 at 5:35 PM, James Teh  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  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  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]

On Wed, Feb 15, 2017 at 3:12 PM, Dominic Mazzoni 
wrote:

> On Wed, Feb 15, 2017 at 12:07 PM Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> 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?
>>
>
> I guess we could just count them without actually creating them if someone
> calls nRelations. Right now we create them all when accessed. If AT is
> using relationTargetsOfType then I agree that's pretty efficient.
>

We may consider to deprecate IAccessibleRelation interface methods, and
then occasionally remove implementations. I assume the methods can be
useful for tools only, where it's important to list all exposed relations.
However as long as the spec defines all possible relation types, then it
shouldn't be a problem to check all relations by relationTargetsOfType.


>
>
>> 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.
>>
>
> It reminds me of IA2TextSpecialOffsets which can be passed to most of the
> caret and selection APIs. Since the enums are defined in the IDL and
> well-documented they're not that bad.
>
> Either way is fine. I just don't want to leave out the ability to jump to
> the top/bottom of a column.
>

So am I. Let's see what Jamie says. It seems we flooded well his morning
inbox :)
___
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 
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 
>> 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]

On Wed, Feb 15, 2017 at 2:06 PM, Dominic Mazzoni 
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.

Not sure what to do with the table with lots of holes in it. The best
> option for the user might be to just navigate linearly in the document
> until they reach the next cell.
>

I'm not sure if AT really need to care about these, Jamie might have some
thinking on it, but if we need then it could be also solved by extra pair
of relations like NEXT/PREV_IN_FLOW or if existing LEFT/RIGHT returned a
previous/next cell which is before/after the given cell.


>
>
> On Wed, Feb 15, 2017 at 11:00 AM Alexander Surkov <
> surkov.alexan...@gmail.com> wrote:
>
>> 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 
>> 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  wrote:
>> > Let's get this discussion st

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 
> 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  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 
>> 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
>> this.
>> >>

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

[Alexander Surkov]

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  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  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 this.
>> I filed a new issue with an example:
>>
>> https://github.com/nvaccess/nvda/issues/5655
>>
>> I think it'd make sense for screen readers to be as robust as possible at
>> dealing with sparse tables using existing APIs. Then if we also want to add
>> additional APIs to make this faster and easier, that's great too.
>>
>> On Tue, Jan 5, 2016 at 2:50 PM James Teh  wrote:
>>>
>>> I suppose we could do that, but it's pretty inelegant. Oh look, we have a
>>> table interface... but uh, sometimes it's not very useful, so you might need
>>> to use tree navigation. It's not so bad for columns i guess, but see below
>>> for rows.
>>
>>
>> As I said, I'm totally happy to implement extensions to the table
>> interface, I'm just pointing out that there are APIs available as a fallback
>> in the meantime.
>>
>> It's up to you. Maybe as a compromise you could look at the aria-hidden
>> table above and make NVDA slightly more robust in the presence of missing
>> cells, then when we extend IAccessibleTable2 you could make it handle these
>> cases well.
>>
>>> Navigating to the next row has two problems:
>>> 1. It's not a simple navigation, since there might be
>>> thead/tbody/rowgroup elements to think about. Sure, it's just a depth-first
>>> traversal, but now we're starting to get fairly complicated for what should
>>> be a simple operation.
>>> 2. What if the next row doesn't include that column, but there is a row 3
>>> rows beyond that that does? Surely we should move to the row with the
>>> matching column. That's not possible with your algorithm.
>>
>>
>> I'm not sure that's the best behavior, because the user wouldn't realize
>> they skipped over rows containing content. Think about what happens when you
>> move the cursor in a text editor: when you press the down arrow, it tries to
>> move to the same column in the next line. However, if there's no text at
>> that column position in the next line, it moves the cursor to the closest
>> character in that line.
>>
>
___
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]

Thank you!

On Fri, Oct 21, 2016 at 1:26 PM, Joseph Scheuhammer 
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  > <mailto:ja...@nvaccess.org>> wrote:
> >
> >     placeholder-text is fine with me.
> >
> > On Fri, Oct 21, 2016 at 12:02 AM, Alexander Surkov
> > 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  > <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
> >> 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>
> >>
> >> www.vfo-group.com <http://www.vfo-grou

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  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  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 
>>> 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 ; James Teh >>> >
>>>> *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 sema

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  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 
> 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 ; James Teh 
>> *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 
>> wrote:
>>
>> Hi All:
>>
>> I have been looking at how the HTML placeholder attribute is supported by
>> IA2.
>>
>> According to the HTML accessibility API ma

[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  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] Fwd: figure role backgrounds

[Alexander Surkov]

On Thu, Sep 15, 2016 at 5:53 PM, Rich Schwerdtfeger 
wrote:

> Hi Alex,
>
> That is indeed what ARIA has as the HTML AAM points to that mapping in
> ARIA Core: http://rawgit.com/w3c/aria/master/core-aam/core-aam.
> html#role-map-figure
>
> and the HTML AAM points to it. So, for the figure role we are all set.
>
> Is that currently implemented in Firefox when you an element with
> role=“figure”? … ROLE_SYSTEM_GROUPING and xml-roles:figure object attrib
>

It's not yet implemented in Firefox. Btw, do you know if other browsers
have supported it?


>
> If you do already, I will work with Windows ATVs to start supporting it on
> Windows.
>

HTML:figure is accessible in Firefox. ARIA role='figure' should have
identical mapping. If screen readers support HTML:figure, then they don't
have to make any extra effort to support ARIA role='figure'.



> Please map that for for SVG elements when it is applied as well. Then we
> can discuss their participating in a list of figures in ATVs as part of the
> AT UIs.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
>
> On Sep 15, 2016, at 1:00 PM, Alexander Surkov  wrote:
>
> Thank you, Marcos.
>
> I'm getting lost in the discussion as it goes in two separate
> threads/groups (IAccessible2 one and SVG groups).
>
> I buy Doug's argument [1] that non browser SVG tools may not implement
> HTML, but still they are keen to support ARIA to make their products
> accessible. This argument can be a justification for ARIA figure role
> I think.
>
> Having said that, I'm adherent to the idea of re-using HTML elements
> in SVG documents. The author should be able to use standard HTML and
> SVG blocks to make the content accessible.  perhaps is
> not the most convenient structure to embed HTML into SVG, but it
> works, which makes ARIA role='figure' less valuable in the browser's
> word.
>
> I don't think that ARIA role='figure', implemented in the browsers,
> may harm anyone, I'd be interesting though to hear from other browsers
> on this topic.
>
> Rich, I think ARIA role='figure' should have same IAccessible2 mapping
> as HTML figure element has, which is ROLE_SYSTEM_GROUPING and
> xml-roles:figure object attribute.
>
> Thank you.
> Alexander.
>
> [1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0053.html
>
> On Thu, Sep 15, 2016 at 1:19 AM, Marcos Caceres 
> wrote:
>
> On September 15, 2016 at 2:10:09 PM, Rich Schwerdtfeger
> (richsch...@gmail.com) wrote:
>
> Alex, both Doug and Anna have expressed to you the opinion of the SVG
> working group to not
> have those elements in SVG. At this point the discussion on adding or
> using them is not
> productive.
>
>
> With all due respect, if Mozilla is supposed to implement this, we
> need our queries addressed properly.
>
> Mozilla's position is that developers should be able to use existing
> HTML element/attributes in SVG, where they are
> semantically/structurally useful. It clearly doesn't make sense to
> redefine things that are in HTML in some new SVG version.
>
> I would kindly ask that Alex's requests for clarification are addressed.
>
> Kind regards,
> Marcos
>
>
>
> ___
> 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] Fwd: figure role backgrounds

[Alexander Surkov]

Thank you, Marcos.

I'm getting lost in the discussion as it goes in two separate
threads/groups (IAccessible2 one and SVG groups).

I buy Doug's argument [1] that non browser SVG tools may not implement
HTML, but still they are keen to support ARIA to make their products
accessible. This argument can be a justification for ARIA figure role
I think.

Having said that, I'm adherent to the idea of re-using HTML elements
in SVG documents. The author should be able to use standard HTML and
SVG blocks to make the content accessible.  perhaps is
not the most convenient structure to embed HTML into SVG, but it
works, which makes ARIA role='figure' less valuable in the browser's
word.

I don't think that ARIA role='figure', implemented in the browsers,
may harm anyone, I'd be interesting though to hear from other browsers
on this topic.

Rich, I think ARIA role='figure' should have same IAccessible2 mapping
as HTML figure element has, which is ROLE_SYSTEM_GROUPING and
xml-roles:figure object attribute.

Thank you.
Alexander.

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

On Thu, Sep 15, 2016 at 1:19 AM, Marcos Caceres  wrote:
> On September 15, 2016 at 2:10:09 PM, Rich Schwerdtfeger
> (richsch...@gmail.com) wrote:
>> Alex, both Doug and Anna have expressed to you the opinion of the SVG 
>> working group to not
>> have those elements in SVG. At this point the discussion on adding or using 
>> them is not
>> productive.
>
> With all due respect, if Mozilla is supposed to implement this, we
> need our queries addressed properly.
>
> Mozilla's position is that developers should be able to use existing
> HTML element/attributes in SVG, where they are
> semantically/structurally useful. It clearly doesn't make sense to
> redefine things that are in HTML in some new SVG version.
>
> I would kindly ask that Alex's requests for clarification are addressed.
>
> Kind regards,
> Marcos
___
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  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 
> 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 ; James Teh 
>> *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 
>> 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-place

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

[Alexander Surkov]

Hi, Rich.


On Wed, Sep 14, 2016 at 4:56 PM, Richard Schwerdtfeger 
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 
> Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
> To: Rich Schwerdtfeger 
> Cc: IA2 List , Alexander
> Surkov 
> 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  > 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 
> *Subject: **Re: figure role backgrounds*
> *Date: *September 12, 2016 at 11:55:09 PM CDT
> *To: *Alexander Surkov 
> *Cc: *ARIA Working Group , SVG-A11y TF <
> public-svg-a...@w3.org>, Richard Schwerdtfeger 
>
> 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

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 
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 
> *Subject: **Re: figure role backgrounds*
> *Date: *September 12, 2016 at 11:55:09 PM CDT
> *To: *Alexander Surkov 
> *Cc: *ARIA Working Group , SVG-A11y TF <
> public-svg-a...@w3.org>, Richard Schwerdtfeger 
>
> 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
>content (either because they are following un-linked cross references from
>the main text, or

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

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.

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

On Thu, Sep 8, 2016 at 7:22 AM, Alexander Surkov  wrote:

> 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  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 
>> 
>> To: Brett Lewis  
>> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org"
>>   ,
>> "jdi...@igalia.com"  
>> , "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 
>> 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 
>> *Cc:* Richard Schwerdtfeger ; 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  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 

Re: [Accessibility-ia2] HTML placeholder attribute

[Alexander Surkov]

Jamie, do you have objections?

On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis  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 ; James Teh 
> *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  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

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  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 
> 
> To: James Teh  
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list
> 
> , Brett Lewis
>  , Joanmarie
> Diggs  , Dominic Mazzoni
>  
> 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  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  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  
> 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. Th

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  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  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  
>> 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 description when
>>error messages are present and reconst

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

On Wed, Sep 7, 2016 at 3:25 PM, 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.
>

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 
> To: Brett Lewis 
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org" <
> ja...@nvaccess.org>, "jdi...@igalia.com" , "
> accessibility-...@lists.linux-foundation.org"  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 
> 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 
> *Cc:* Richard Schwerdtfeger ; 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  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  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 
> 
> To: Brett Lewis  
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org"
>   ,
> "jdi...@igalia.com"  
> , "accessibility-...@lists.linux-foundation.org"
>   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 
> 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 
> *Cc:* Richard Schwerdtfeger ; 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  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
>
>
>
>
>
>
>
>
> --
> 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] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[Alexander Surkov]

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  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  
> 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 description when
>error messages are present and reconstruct the description computation
>within the assistive technology.
>4. Lead either browsers or authors to devise their own string-based
>tokenization capability. Because aria-errormessage is a separate
>relationship, there will be designers and developers who want to ensure
>there is a method for parsing the string into its separate components. This
>would reduce the robustness of the solution and create both inconsistencies
>and complexity, especially when localizing implementations.
>5. Introduce serious problems with globalization: namely there is no
>clean way to concatenate the 2 strings in a way that will make sense. We
>cannot put in a space as some languages don't have them (Mandarin).
>Concatenating them together does not read properly.
>
>
> The aria-errormessage relationship is intended to address long-standing
> accessibility issues faced by both developers and end users. The energy
> required to find effective remedies to those issues will definitely pay
> dividends for assistive technology users.
>
> Would each of you weigh in. Again this is now holding up 3 working groups
> going on 3 weeks now.  Do we agree on not concatenating the two strings?
>
> 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
>
>
>
>
> --
> 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
>
>

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  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 
> *Cc:* Richard Schwerdtfeger ; 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  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 
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 
> 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 
> 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
>> >> 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 > >> <mailto:richsch...@gmail.com>>
>> >> *Cc:* Alexander Surkov > >> <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
>> >> mailto:cl...@alum.mit.edu>>; Joanmarie Diggs
>> >> mailto:jdi...@igalia.com>>; IA2 List
>> >> > >> <mailto:accessibility-...@lists.linux-foundation.org>&

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  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
> >> 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  >> <mailto:richsch...@gmail.com>>
> >> *Cc:* Alexander Surkov  >> <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
> >> mailto:cl...@alum.mit.edu>>; Joanmarie Diggs
> >> mailto:jdi...@igalia.com>>; IA2 List
> >>  >> <mailto:accessibility-...@lists.linux-foundation.org>>; ARIA
> Working
> >> Group mailto:public-a...@w3.org>>; Steven
> >> Faulkner 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 gue

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  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
> > 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  > <mailto:richsch...@gmail.com>>
> > *Cc:* Alexander Surkov  > <mailto:surkov.alexan...@gmail.com>>; Joseph Scheuhammer
> > mailto:cl...@alum.mit.edu>>; Joanmarie Diggs
> > mailto:jdi...@igalia.com>>; IA2 List
> >  > <mailto:accessibility-...@lists.linux-foundation.org>>; ARIA Working
> > Group mailto:public-a...@w3.org>>; Steven
> > Faulkner 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, 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 for

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 
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 
> *Cc:* Alexander Surkov ; Joseph Scheuhammer <
> cl...@alum.mit.edu>; Joanmarie Diggs ; IA2 List <
> accessibility-...@lists.linux-foundation.org>; ARIA Working Group <
> public-a...@w3.org>; Steven Faulkner 
> *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  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  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 le

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

[Alexander Surkov]

Landed.

On Tue, Aug 23, 2016 at 8:43 PM, James Teh  wrote:

> +  /** An object representing a navigational landmark, a region on a page to
> +   which the user may want quick access, such as navigating, searching,
> +   perusing the primary content.
>
>
> nit: I'd change the last bit to "such as a navigation area, a search
> facility or the main content of a page".
>
> Otherwise, looks fine to me!
>
> Thanks,
> Jamie
>
>
> On 24/08/2016 2:05 AM, Alexander Surkov wrote:
>
> 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  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
>>
>>
>
> --
> 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] aria-details and aria-errormessage mapping

[Alexander Surkov]

ils 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.
>
> 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  
> 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
>
>
&g

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  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 
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 
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs 
> 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 
> wrote:
>
> Those would be great. What would you have for reverse relationships?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov 
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs , 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]

On Wed, Aug 10, 2016 at 4:52 PM, Joanmarie Diggs  wrote:

> The reason one might wish to have the reverse relationship is if the
> error messages could be encountered independently. Consider the
> following scenario:
>
> 1. User fills out form
> 2. User presses submit
> 3. New page loads displaying the errors at the top with the form fields
>reproduced below the list of errors
>
> (Yeah, it's artificial. But, you know, authors...)
>
> In the above scenario, the AT didn't provide the navigation to the error
> as the result of some command. Thus the AT doesn't have anything to keep
> track of.
>

if UI doesn't help the user to navigate to the errors, then AT probably
shouldn't fix the UI.


>
> IF ATs will be expected to provide navigation between error messages and
> elements with errors regardless of circumstances, THEN I think we need
> the reverse relationship because doing a complete tree dive looking for
> the element which points to the error is not reasonable.
>
> On the other hand, if my scenario is so artificial that it would never
> happen, then I'm fine with having to keep track of the field before
> moving the user to the error.
>

I would hold up on adding reverse relations until we are sure we have a
real use case for it.



>
> --joanie
>
>
> On 08/10/2016 08:33 AM, Alexander Surkov 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  > <mailto:sch...@us.ibm.com>> wrote:
> >
> > Those would be great. What would you have for reverse relationships?
> >
> >
> >
> > Rich Schwerdtfeger
> >
> >
> >
> > - Original message -
> > From: Alexander Surkov  > <mailto:surkov.alexan...@gmail.com>>
> > To: "accessibility-ia2@lists.linuxfoundation.org
> > <mailto:accessibility-ia2@lists.linuxfoundation.org>"
> >  > <mailto:accessibility-ia2@lists.linuxfoundation.org>>, James Teh
> > mailto:ja...@nvaccess.org>>, Joanmarie
> > Diggs mailto: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
> > <https://www.w3.org/TR/wai-aria-1.1/#aria-details>
> > [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
> > <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]

Cool.

Will be implemented in Firefox 51 (nightly).

On Wed, Aug 10, 2016 at 9:51 PM, James Teh  wrote:

> I'm happy with this.
>
> On 11/08/2016 12:01 AM, Alexander Surkov wrote:
>
> Let's go with ROLE_SYSTEM_GROUPING then until Jamie has objections.
>
> On Wed, Aug 10, 2016 at 8:54 AM, Joanmarie Diggs 
> 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
>>
>>
>
> --
> 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] 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 
> wrote:
>
>> Those would be great. What would you have for reverse relationships?
>>
>>
>>
>> Rich Schwerdtfeger
>>
>>
>>
>> - Original message -
>> From: Alexander Surkov 
>> To: "accessibility-ia2@lists.linuxfoundation.org" <
>> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
>> ja...@nvaccess.org>, Joanmarie Diggs , 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] Fwd: IA2 Role Landmark

[Alexander Surkov]

Jamie, are you good with
1) adding IA2_ROLE_LANDMARK and
2) deprecating IA2_ROLE_FORM?

Thanks.
Alex.

On Mon, Apr 18, 2016 at 11:04 AM, Joseph Scheuhammer 
wrote:

> On 2016-04-18 10:41 AM, Rich Schwerdtfeger wrote:
> >
> > So, this is pretty much what I expected. The net is you should use the
> > new IA2 landmark role vs. the Form role for newer versions of firefox
> > (along with exposing the xml-roles=“form”) in newer versions of
> > Firefox and this should be reflected in the Core mapping spec.
> >
>
> To be concrete: the current MSAA+IA2 mapping of role="form" is to map it
> to IA2_ROLE_FORM [1].  Is the suggestion to change that to
> IA2_ROLE_LANDMARK + xml-roles:"form"?
>
> If so, are the other platforms affected?  I imagine for
> interoperability, you would want ATK/AT-SPI to change from ROLE_FORM to
> ROLE_LANDMARK.
>
> UIA seems to have it covered, in that they store both a Control type
> (Group) and a Landmark Type (form) -- does that remain unchanged?
>
> [1] https://w3c.github.io/aria/core-aam/core-aam.html#role-map-form
>
> --
> joseph.
>
> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>  - C. Carter -
>
>
___
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  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-details and aria-errormessage mapping

[Alexander Surkov]

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 
wrote:

> Those would be great. What would you have for reverse relationships?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov 
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs , 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]

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 
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 
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie
> Diggs 
> 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 feed role

[Alexander Surkov]

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]

Hi, all. I'm not yet clear on definition for the new role. What role should
we use to expose a 'landmark' role that have a better role match, like FORM
role?

On Tue, Feb 23, 2016 at 10:48 PM, Rich Schwerdtfeger 
wrote:

> Alright, please add the role to IA2. We will update the ARIA mapping spec
> and I will let some of the ATs know and We will need to let Google know as
> well.
>
> Rich
>
> Sent from my iPhone
>
> > On Feb 23, 2016, at 4:50 PM, James Teh  wrote:
> >
> > That's a fair justification. We don't have a collections interface for
> IA2, so if we did want to fetch all landmarks, we have to walk the entire
> tree in-process, in which case checking the role is about the same as
> checking xml-roles. Still, it does make sense and I'm happy to accept it
> given the consensus.
> >
> > I'll leave convincing the other Windows ATs up to someone else, though...
> >
> > Jamie
> >
> >> On 24/02/2016 4:34 AM, 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
> >
> > --
> > 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] 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] new IA2 landmark role

[Alexander Surkov]

Hi, Rich. Redirecting the proposal to IA2 group, I cannot add roles on my
own :)

Are there ATK-related discussions about the new role?

On Tue, Jan 26, 2016 at 3:17 PM, Richard Schwerdtfeger  wrote:

> Hi Alex,
>
> We changed the region role to be a subclass of ARIA landmarks. That
> manifests itself here:
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-region
>
> Would you please add a role of landmark to IA2 to be equivalent tot he
> ATK/ATSPI role for landmark. So you would have
> role=“IA2_ROLE_LANDMARK”
> Object attribute: xml-roles:region
>
>
>
___
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]

Gecko implementation has been landed on Mozilla Nightly [1].
Thanks.
Alexander.

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

On Fri, Dec 18, 2015 at 11:57 AM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> 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  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]

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  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]

Don't we need an extra aMaxRanges argument? It seems any other
array-related method has it.

On Mon, Dec 14, 2015 at 10:13 AM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> Yep, the first part was about a small correction of your wording. I pushed
> the changes into a master branch [1]. I hope it looks good now.
>
> [1] http://git.linuxfoundation.org/?p=a11y/ia2.git;a=summary
>
> On Tue, Dec 8, 2015 at 6:08 PM, James Teh  wrote:
>
>> Wait. Sorry. I think I misinterpreted you. I read your message as saying
>> that you wanted to include just that one sentence. I'm guessing you
>> actually meant you wanted to clarify one sentence in the text I proposed.
>> In the latter case, I totally agree; I should have been clearer about
>> selection in my text.
>>
>> My apologies for the misunderstanding.
>>
>> Jamie
>>
>>
>> On 9/12/2015 9:04 AM, James Teh wrote:
>>
>> But it's *not* the start of the range. And if you're going to say start
>> and end, you may as well rename anchor and active to start and end. :)
>>
>> Jamie
>>
>> On 9/12/2015 5:50 AM, Alexander Surkov wrote:
>>
>> 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  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
>>>
>>>
>>
>> --
>> 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
>>
>>
>> --
>> 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]

Yep, the first part was about a small correction of your wording. I pushed
the changes into a master branch [1]. I hope it looks good now.

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

On Tue, Dec 8, 2015 at 6:08 PM, James Teh  wrote:

> Wait. Sorry. I think I misinterpreted you. I read your message as saying
> that you wanted to include just that one sentence. I'm guessing you
> actually meant you wanted to clarify one sentence in the text I proposed.
> In the latter case, I totally agree; I should have been clearer about
> selection in my text.
>
> My apologies for the misunderstanding.
>
> Jamie
>
>
> On 9/12/2015 9:04 AM, James Teh wrote:
>
> But it's *not* the start of the range. And if you're going to say start
> and end, you may as well rename anchor and active to start and end. :)
>
> Jamie
>
> On 9/12/2015 5:50 AM, Alexander Surkov wrote:
>
> 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  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
>>
>>
>
> --
> 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
>
>
> --
> 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]

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  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 
> 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  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:23 PM, James Teh  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] aria-current thread on ia2

[Alexander Surkov]

On Wed, Dec 2, 2015 at 6:05 PM, James Teh  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: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] 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  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  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  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  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

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

[Alexander Surkov]

On Thu, Oct 29, 2015 at 9:25 PM, James Teh  wrote:

> On 30/10/2015 3:49 AM, Alexander Surkov wrote:
>
> -  The nodes in the IA@_Range structure may be generic
>> IAccessibles and not necessarily IAccessibleText. That would cover the case
>> of a composite image with an array of image children that can be selected
>> individually.
>>
> 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.
> Otherwise, things get confusing for text.
>

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.


>
> * if returned accessible is generic IAccessible then the integer is child
> index. The point is *before* a referred child.
>
> 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'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?


> I realise this makes things different to text, but text is a bit different
> in that you generally want to expand text to word, line, etc., whereas for
> non-text cases, you're more interested in just getting at the objects.
> Remember, the objects might not be siblings; e.g. in a tree view.
>

tree view shouldn't be different, since (accessible, offset) pairs
basically describe points in the tree.


>
>
>>
>> -  In some cases it would be good to specify which limit of the
>> range is the anchor and which the active end. We could add that to the
>> structure as an additional member, or simply document the convention that
>> start = anchor and end = active. If we go with the latter, then start does
>> not have to be <= end in the Accessible order.
>>
> This would certainly be useful, particularly for braille. I have a slight
> preference for a boolean or similar to specify which end is active/anchor.
> Alternatively, we could rename start and end to anchor and active.
>




>
> 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 Thu, Oct 29, 2015 at 2:14 PM, Andres Gonzalez  wrote:

> Also inline, prefaced with AG:.
>
>
>
> -  The nodes in the IA@_Range structure may be generic
> IAccessibles and not necessarily IAccessibleText. That would cover the case
> of a composite image with an array of image children that can be selected
> individually.
>
>
>
> So the point is:
> * if returned accessible implements IAccessibleText then the integer is an
> offset within the accessible
>
> * if returned accessible is generic IAccessible then the integer is child
> index. The point is *before* a referred child. If the integer equals to
> children count then the point is after a last child.
>
> Is that correct? If so then what would you name 'startOffset' and
> 'endOffset' struct members since 'offset' doesn't apply longer.
>
>
>
> AG: exactly right. I’d keep the names start/endOffset, since in both cases
> are offsets in a sequence, of chars or objects.
>

This seems flexible and generic. I guess you can even do it for listbox
selection. If we do that then we need to change accessibleWithCaret docs as
well to keep them in sync.

I would have something different for 'offset' naming since 'offset' term is
tightly related with text interface in my mind, but I'm not sure I have
good ideas for this.


>
>
> -  In some cases it would be good to specify which limit of the
> range is the anchor and which the active end. We could add that to the
> structure as an additional member, or simply document the convention that
> start = anchor and end = active. If we go with the latter, then start does
> not have to be <= end in the Accessible order.
>
>
>
> Can you give an example please? I'm not sure I follow the use case.
>
>
>
> AG: in a list with selected items, you may want to know the last selected
> item, which should be the active end of the selection range. Same with the
> selected text in a doc, client may need to know whether you were selecting
> text in a line left to right or in reverse. That info may be inferred by
> client if it combines info about focus or caret position with the selection
> range. But in many cases the server could make it easier for the client by
> exposing the anchor and active ends since the server has to keep track of
> that anyway.
>
>
It sounds good with me. I like start = anchor and end = active approach but
I'm curious whether it is a tri-state with 'undefined' as 3rd state, when
the accessible doesn't have focus and caret.


>
> Best regards,
>
>
>
> --Andres.
>
>
>
> *From:* accessibility-ia2-boun...@lists.linuxfoundation.org [mailto:
> accessibility-ia2-boun...@lists.linuxfoundation.org] *On Behalf Of *Alexander
> Surkov
> *Sent:* Thursday, October 29, 2015 9:02 AM
> *To:* accessibility-ia2@lists.linuxfoundation.org; James Teh
> *Subject:* [Accessibility-ia2] a new method to retrieve the selection
>
>
>
> 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] a new method to retrieve the selection

[Alexander Surkov]

Hey, Andres! Answering inline.

On Thu, Oct 29, 2015 at 1:36 PM, Andres Gonzalez  wrote:

> Hello Alex, Jamie and all: a couple of thoughts for consideration.
>
> -  The nodes in the IA@_Range structure may be generic
> IAccessibles and not necessarily IAccessibleText. That would cover the case
> of a composite image with an array of image children that can be selected
> individually.
>

So the point is:
* if returned accessible implements IAccessibleText then the integer is an
offset within the accessible
* if returned accessible is generic IAccessible then the integer is child
index. The point is *before* a referred child. If the integer equals to
children count then the point is after a last child.

Is that correct? If so then what would you name 'startOffset' and
'endOffset' struct members since 'offset' doesn't apply longer.


> -  In some cases it would be good to specify which limit of the
> range is the anchor and which the active end. We could add that to the
> structure as an additional member, or simply document the convention that
> start = anchor and end = active. If we go with the latter, then start does
> not have to be <= end in the Accessible order.
>

Can you give an example please? I'm not sure I follow the use case.

>
>
> Best regards,
>
>
>
> --Andres.
>
>
>
> *From:* accessibility-ia2-boun...@lists.linuxfoundation.org [mailto:
> accessibility-ia2-boun...@lists.linuxfoundation.org] *On Behalf Of *Alexander
> Surkov
> *Sent:* Thursday, October 29, 2015 9:02 AM
> *To:* accessibility-ia2@lists.linuxfoundation.org; James Teh
> *Subject:* [Accessibility-ia2] a new method to retrieve the selection
>
>
>
> 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

[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]

Agree. Firefox exposes a current item within a widget as active state both
in ATK and IA2. Reusing it for aria-current we will run into conflict.

I don't have data about IA2 activate state usage, I can check it out if
needed.

On Wed, Sep 2, 2015 at 12:06 AM, James Teh  wrote:

> Hi all,
>
> One problem here is that the term "active" is somewhat ambiguous,
> especially given aria-activedescendant.
>
> Joanie, for a container which uses aria-activedescendant, do you expect
> that ATK_STATE_ACTIVE would be exposed on the element which is currently
> the active descendant? That also fits the definition: "the active
> subelement within a container or table". I believe this is how
> IA2_STATE_ACTIVE is currently being used.
>
> If you do expect this would be the case, we have a problem because there
> are apparently cases where aria-current and aria-activedescendant can apply
> to different descendants:
> https://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0287.html
>
> On the other hand, I can totally see how this definition also fits
> aria-current. That ambiguity is concerning.
>
> aria-current seems a lot like "selected" to me. However, I understand
> there are cases where selected and current conflict; e.g. the tree example
> in the spec.
>
> Alex, do we know if existing ATs are using IA2_STATE_ACTIVE? NVDA isn't at
> this stage.
>
> Jamie
>
>
> On 1/09/2015 6:29 AM, Joanmarie Diggs wrote:
>
>> Hi Alex.
>>
>> Up through ATK 2.14 [1], the definition of ATK_STATE_ACTIVE was:
>>
>>  Indicates a window is currently the active window, or is an active
>>  subelement within a container or table
>>
>> That struck us as odd. Can a window be "an active subelement within a
>> container or table"? We figured that the part after the comma referred
>> to objects which were not windows.
>>
>> In order to clarify that, and also distinguish it from FOCUSED and
>> SELECTED, we updated the docs in ATK 2.16 [2]:
>>
>>  Indicates a window is currently the active window, or an object is
>>  the active subelement within a container or table. ATK_STATE_ACTIVE
>>  should not be used for objects which have ATK_STATE_FOCUSABLE or
>>  ATK_STATE_SELECTABLE: Those objects should use ATK_STATE_FOCUSED
>>  and ATK_STATE_SELECTED respectively. ATK_STATE_ACTIVE is a means to
>>  indicate that an object which is not focusable and not selectable
>>  is the currently-active item within its parent container.
>>
>> Being the active subelement within a container or table does sound like
>> aria-current (doesn't it?).
>>
>> Lastly, note that we do NOT expect you to do any validation, and there
>> may be cases where an author has a current object which happens to be
>> focusable. That's OK. :) We were more concerned about desktop toolkits
>> getting the states wrong.
>>
>> --joanie
>>
>> [1] https://developer.gnome.org/atk/2.14/atk-AtkState.html#AtkStateType
>> [2] https://developer.gnome.org/atk/2.16/atk-AtkState.html#AtkStateType
>>
>> On 08/31/2015 03:54 PM, Alexander Surkov wrote:
>>
>>> Hi, Joseph. 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?
>>> Thanks.
>>> Alex.
>>>
>>> On Mon, Aug 31, 2015 at 3:45 PM, Joseph Scheuhammer >> <mailto:cl...@alum.mit.edu>> wrote:
>>>
>>>  Hi Alex,
>>>
>>>  I have finalized the ATK/AT-SPI mappings of aria-current [1], and
>>>  based on that, have a proposal for the MSAA+IA2 mappings.
>>>
>>>  However, I've been following the related mozilla bug [2], and
>>>  likely, you will have thoughts.  Has there been any progress with
>>>  respect to FF/IA2/aria-current?
>>>
>>>  For what it's worth, it appears that AXAPI will be adding an
>>>  AXCurrent property whose value is that given by aria-current, that
>>>  is, one of page, step, location, date, time, true, or false [3].
>>>
>>>  Thanks.
>>>
>>>  [1]
>>> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrent
>>>  [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1104947
>>>  [3] https://bugs.webkit.org/attachment.cgi?id=260300&action=diff
>>>
>>>  --
>>>  j

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  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

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]

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?

On Mon, Aug 31, 2015 at 4:29 PM, Joanmarie Diggs  wrote:

> Hi Alex.
>
> Up through ATK 2.14 [1], the definition of ATK_STATE_ACTIVE was:
>
> Indicates a window is currently the active window, or is an active
> subelement within a container or table
>
> That struck us as odd. Can a window be "an active subelement within a
> container or table"? We figured that the part after the comma referred
> to objects which were not windows.
>
> In order to clarify that, and also distinguish it from FOCUSED and
> SELECTED, we updated the docs in ATK 2.16 [2]:
>
> Indicates a window is currently the active window, or an object is
> the active subelement within a container or table. ATK_STATE_ACTIVE
> should not be used for objects which have ATK_STATE_FOCUSABLE or
> ATK_STATE_SELECTABLE: Those objects should use ATK_STATE_FOCUSED
> and ATK_STATE_SELECTED respectively. ATK_STATE_ACTIVE is a means to
> indicate that an object which is not focusable and not selectable
> is the currently-active item within its parent container.
>
> Being the active subelement within a container or table does sound like
> aria-current (doesn't it?).
>
> Lastly, note that we do NOT expect you to do any validation, and there
> may be cases where an author has a current object which happens to be
> focusable. That's OK. :) We were more concerned about desktop toolkits
> getting the states wrong.
>
> --joanie
>
> [1] https://developer.gnome.org/atk/2.14/atk-AtkState.html#AtkStateType
> [2] https://developer.gnome.org/atk/2.16/atk-AtkState.html#AtkStateType
>
> On 08/31/2015 03:54 PM, Alexander Surkov wrote:
> > Hi, Joseph. 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?
> > Thanks.
> > Alex.
> >
> > On Mon, Aug 31, 2015 at 3:45 PM, Joseph Scheuhammer  > <mailto:cl...@alum.mit.edu>> wrote:
> >
> > Hi Alex,
> >
> > I have finalized the ATK/AT-SPI mappings of aria-current [1], and
> > based on that, have a proposal for the MSAA+IA2 mappings.
> >
> > However, I've been following the related mozilla bug [2], and
> > likely, you will have thoughts.  Has there been any progress with
> > respect to FF/IA2/aria-current?
> >
> > For what it's worth, it appears that AXAPI will be adding an
> > AXCurrent property whose value is that given by aria-current, that
> > is, one of page, step, location, date, time, true, or false [3].
> >
> > Thanks.
> >
> > [1]
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrent
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1104947
> > [3] https://bugs.webkit.org/attachment.cgi?id=260300&action=diff
> >
> > --
> > 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] IA2 mapping of aria-current

[Alexander Surkov]

Hi, Joseph. 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?
Thanks.
Alex.

On Mon, Aug 31, 2015 at 3:45 PM, Joseph Scheuhammer 
wrote:

> Hi Alex,
>
> I have finalized the ATK/AT-SPI mappings of aria-current [1], and based on
> that, have a proposal for the MSAA+IA2 mappings.
>
> However, I've been following the related mozilla bug [2], and likely, you
> will have thoughts.  Has there been any progress with respect to
> FF/IA2/aria-current?
>
> For what it's worth, it appears that AXAPI will be adding an AXCurrent
> property whose value is that given by aria-current, that is, one of page,
> step, location, date, time, true, or false [3].
>
> Thanks.
>
> [1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrent
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1104947
> [3] https://bugs.webkit.org/attachment.cgi?id=260300&action=diff
>
> --
> 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] 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 
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 
> 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  > 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 
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: Brett Lewis , 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* > wrote:
>>
>>That does not make sense. It is essentially the same attribute.
>>
>>
>>Rich Schwerdtfeger
>>
>>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*
>>>
>>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/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* > wrote:
>>   How do you expose rowspan and colspan for HTML tables?
>>
>>
>>   Rich Schwerdtfeger
>>
>>   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*
>>   >
>>   To: Brett Lewis <*ble...@freedomscientific.com*
>>   >
>>   Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank
>>   DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter <
>>   *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.linu

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 
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 
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Brett Lewis , 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* > 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*
>>
>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/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* > 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*
>   >
>   To: Brett Lewis <*ble...@freedomscientific.com*
>   >
>   Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank
>   DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter <
>   *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* >
>   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 

Re: [Accessibility-ia2] rowspan and colspan

[Alexander Surkov]

Because of multiple edits I made for the previous email, it is not so clear
as I would expect :) So putting it into different words.

It sounds that main problem of ARIA span is that, it can be used to span
the missed cells. In this case it cannot be exposed via IAccessibleTable
interface as a cell extent because cell index + cell extent should point to
the missed cell, however it points to the last cell in DOM. Jamie's
suggestion if I read it right was to put ARIA span as an object attribute
if it serves for informational proposes only, otherwise expose it via
IAccessibleTable as we do that for HTML. It sounds reasonable with me. If
there are no objections then that's the way to go I think.

On Thu, Jul 16, 2015 at 10:35 AM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> So we do have two use cases.
>
> #1 Example of spanned cells in a table having missed column
> 
>   
> cell 1
> cell 4
>   
>   
> cell 1
> cell 2
> cell 4
>   
> 
>
> #2 Example of spanned cells
> 
>   
> cell 1
>   
>   
> cell 1
> cell 2
>   
> 
>
> 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  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  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,
.

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  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

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

  
cell 1
cell 4
  
  
cell 1
cell 2
cell 4
  


#2 Example of spanned cells

  
cell 1
  
  
cell 1
cell 2
  


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  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

[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

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

[Alexander Surkov]

Agree the current spec is no way perfect but how would it look like?

On Thu, Jun 25, 2015 at 12:46 PM, Trevor Saunders 
wrote:

> On Thu, Jun 25, 2015 at 03:54:24PM +1000, James Teh wrote:
> > On 25/06/2015 3:32 PM, Alexander Surkov wrote:
> > >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?
> > Yup.
>
> I guess that kind of works, but it makes me think we should really think
> about either changing the spec or just refusing to implement it.
>
> Trev
>
> >
> > 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
>
___
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  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] aria-colcount and aria-rowcount mapping

[Alexander Surkov]

I think the reasoning behind that they want to support spreadsheets that
are loaded by parts on the user request.

If we kept table interface to reflect actual table structure, and put aria
row/colcount/index into object attributes, then would it work?
I'm not sure what the use case for this was, but regardless, this is
potentially going to require a pretty big change to table interfaces. In
order to do table navigation, screen readers need to be able to navigate
from a given cell to the cell in the next column or the next row, as well
as being able to fetch all cells in a given row or column. If the numbering
is not sequential, we can't simply increase indexes to do this. No API I
know of supports something like this.

I guess the table interfaces could just deal with sequential, 0-based
coordinates as they always have. We'd then need a way of getting the
numbers from aria-*index and aria-*count to report to the user. However,
that is extremely obscure and starts to raise questions about why we're
doing this in the first place.

Jamie

On 25/06/2015 9:20 AM, Alexander Surkov wrote:

> 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
>
>
-- 
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] 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] 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  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
>> *
>>
>>
>>
>>
>> --
>>
>>
>>
>> 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] Fw: Deprecate IA2_TEXT_BOUNDARY_ALL?

[Alexander Surkov]

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  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
> *
>
>
>
>
> --
>
>
>
> 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]

On Fri, May 1, 2015 at 11:41 AM, Joseph Scheuhammer 
wrote:

> On 2015-05-01 10:52 AM, Alexander Surkov wrote:
>
>> But I'm not sure I see reasoning of *not* mapping it into accessible
>> name/description the way what HTML5 spec suggests.
>>
>
> If the placeholder text is put in both the name and placeholder
> properties, then the same text might be presented twice, once as the name,
> and then echoed as the placeholder.
>
> To combat that, the AT could compare the two, and if identical, just
> present one of them.
>

true, not sure if there are better options.


>
> Or, the placeholder text could be only in the placeholder property, in
> which case, the AT immediately knows there is only placeholder text
> available.  The AT could present it as the name, description, or
> placeholder; whatever is the best user experience.


I really concerned about backward compatibility, all users on Windows will
suffer from this approach. On the other hand I think of placeholder as
secondary concept that is not so important as accessible name. I assume
that some AT might not care to support placeholder at all, if it's exposed
as accessible name. At least this worked more or less well.


>
>
> --
> 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] placeholder mapping

[Alexander Surkov]

On Fri, May 1, 2015 at 10:49 AM, Joseph Scheuhammer 
wrote:

> Btw, Joseph, I didn't really suggested to change GTK+ mappings :)
>>
>
> Oh, sorry, I didn't mean to imply that.  The point was that the mapping
> for placeholder for GTK (desktop) widgets is inconsistent with widgets in
> webpages, and that the HTML mapping spec is not backward compatible with
> that.


That might be ok. I even think that AT can have handle both scenarios by
same script. In Windows world there's no way (yet) to get a placeholder so
I can hardly see that being consistent with GTK+ as an option for them. If
we did that then we would regressed the web. Btw, is it a normal case in
GTK+ to have widgets with placeholder and no name?



> Put another way:  the proposed mapping of aria-placeholder is backward
> compatible with GTK mappings.
>

What is proposed mapping? placeholder object attribute and no
name/description? I'd say aria-placeholder should be rather compatible with
HTML5 placeholder than GTK.


Joanie wrote:
>
>  FWIW, it was made years ago and by several developers (which I point out
>> simply because this isn't something I just decided for this new mapping
>> which we could turn around and change in order to be closely synced).
>>
>>  changing it there now obviously isn't an option. In that case,
>>> this discussion is purely academic for you.
>>>
>> As long as Alex agrees, then you are correct regarding it being purely
>> academic for me.
>>
>
> There might be a sense in which it isn't purely academic.  *If* we decide
> that aria-placeholder is mapped to the acc name or acc description in
> certain cases, then we should avoid making exceptions based on the a11y
> platform.  The accessible name spec would change near step 2G [1], to
> something like:
>
> "Otherwise, if the current node has a non-empty aria-placeholder
> attribute, return the value of aria-placeholder".
>
> But not:
>
> "Otherwise, if the current node has a non-empty aria-placeholder
> attribute, and the AAPI is not ATK/AT-SPI, return the value of
> aria-placeholder".
>
>
> [1] http://w3c.github.io/aria/accname-aam/accname-aam.html#step2G
>
>
> --
> 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] 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 
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 
> To: Joseph Scheuhammer 
> 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*
> > 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]

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 
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
>>
>
> 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

Re: [Accessibility-ia2] placeholder mapping

[Alexander Surkov]

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

On Wed, Apr 29, 2015 at 7:34 AM, James Teh  wrote:

> On 29/04/2015 12:08 AM, Joseph Scheuhammer wrote:
>
>> a few questions is aria-placeholder ever to be used as fallback for
>>> accname/description calculation?
>>>
>> My position is that, yes, aria-placeholder text can be used as a
>> fallback for a name, but the decision should be left to the AT.  The
>> placeholder text should be mapped to a "placeholder" property in all
>> cases, and if the accessible has no "name" property, then the AT can use
>> other properties as alternatives, including the "placeholder" property.
>> That way the AT knows that it's using placeholder text for the name.
>>
> Pardon my lack of awareness here; I'm coming into this discussion cold and
> am not part of the W3C working groups. Feel free to point me at a thread or
> something. I'm curious as to why placeholder shouldn't be exposed as the
> description by UAs. There's certainly an argument for giving the AT as much
> choice as possible, but there's also an argument for abstraction. The
> placeholder essentially describes what a user might enter into the field,
> so it would seem to amp to description quite well where a label is already
> present. I don't quite follow why ATs would want to differentiate this in
> such a major way as to not have it exposed as the description. To put this
> another way, I can possibly understand wanting to have an attribute like
> description-from-placeholder:true or something for ATs that really want
> this for some reason, but I'd imagine that in the majority of cases, this
> wouldn't be used. Am I missing something obvious here?
>
> 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