Re: [Accessibility-ia2] HTML5 meter element

[James Teh]

I think a new role for meter makes sense, yes. There's also precedent for
this: ATK has ATK_ROLE_LEVEL_BAR (I think that's the name).

On Fri, Oct 14, 2016 at 1:42 AM, Alexander Surkov <
surkov.alexan...@gmail.com> wrote:

> 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] HTML elements mapping

[James Teh]

On Fri, Jan 5, 2018 at 7:37 AM, Alexander Surkov  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.

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

Re: [Accessibility-ia2] HTML elements mapping

[James Teh]

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

>
> * @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.

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.

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

[James Teh]

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

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

[James Teh]

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

[James Teh]

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

[James Teh]

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

Re: [Accessibility-ia2] Digital Publishing ARIA module

[James Teh]

On Thu, Sep 29, 2016 at 1:27 AM, Richard Schwerdtfeger 
wrote:

> 1. I support fidelity between Linux and Windows platforms. So, I don't
> have a problem with IA2_ROLE_SECTION. We really have not used
> IA2_ROLE_SECTION anywhere in the Core mapping spec.
>
That's possibly because browsers currently use section as the role for HTML
divs, which are quite generic. However, I don't think this should preclude
its use for more semantic purposes.

So, we will need to investigate these roles:
>
> feed:
> ROLE_SYSTEM_GROUPING + object attribute xml-roles:feed
>
> figure:
> ROLE_SYSTEM_GROUPING + object attribute xml-roles:figure
>
> I would not change figure, as it aligns with HTML, but would you rather
> feed be an IA2_ROLE_SECTION?
>
No. I think grouping makes sense for feed. I realise this justification is
sketchy at best, but grouping doesn't seem to "fit" an arbitrary section of
text. I think of grouping as a group of some common type of thing; e.g. a
group of form controls or a group of feed items.

5. Regarding doc-pagebreak this will definitely take more discussion. So,
> you want to take the name and expose it as an object attribute? Seems
> redundant as this could be addressed with authoring practices (label or
> title is equivalent to the page number) and you could speak it accordingly.
>
I'm not suggesting that doc-pagebreak be any different as far as the dpub
ARIA module is concerned. The name would still be calculated using the same
rules. I'm just suggesting that this name also be exposed as an object
attribute on all top level objects on that page. The reason is that a user
may wish to query the page number at any given point in the document
(rather than waiting to encounter a page break). (A sighted user can just
glance down at the page number, but this is harder for a screen reader
user.) Without this attribute, we'll have to search the tree for a page
break object to get the number. So, it's just an optimisation at the
platform API level.

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

Re: [Accessibility-ia2] Digital Publishing ARIA module

[James Teh]

Hi rich,

Following are some concerns regarding the mapping for IA2:

   1. doc-abstract is mapped to IA2_ROLE_LANDMARK, but it isn't specified a
   subclass of landmark, nor is it mapped to ROLE_LANDMARK for ATK. I think it
   should be mapped to IA2_ROLE_SECTION.
   2. doc-colophon, doc-credit, doc-dedication, doc-epigraph, doc-example
   and doc-qna are all mapped to ROLE_SYSTEM_GROUPING. While this is a bit
   debatable, I'd argue they should be mapped to IA2_ROLE_SECTION, just as
   they are mapped to ROLE_SECTION for ATK.
   3. I think doc-notice and doc-tip should be mapped to IA2_ROLE_NOTE.
   4. This might need some deeper discussion, but I think it could be
   useful to expose the last value of doc-pagebreak as a page-number object
   attribute on all block elements until the next doc-pagebreak. This would
   make it much easier to retrieve the page number at any point, rather than
   having to search for the page break. Joanie, Alex, I'd appreciate your
   thoughts on this.

I have a couple of comments regarding the module itself (not the mappings):

   1. doc-pagebreak says "Name from: content", which precludes the name
   from being specified by the author. is this intentional, and if so, why?
   Arguably, the title attribute isn't content (though I haven't checked what
   the name computation stuff says about that). Even putting that aside, it
   seems like it might be useful to specify the number with aria-label or
   similar.
   2. This creates a huge number of landmarks. This might be too broad a
   conversation for now, but one concern I have with regions (and now this) is
   that we end up with a lot of duplicate information when the landmarks also
   contain a heading, which they often do. So, for example, with a screen
   reader, we might get "Chapter 1. Getting Started, Chapter 1. Getting
   Started heading level 1"; we get it once for the chapter landmark and then
   once for the heading. We can try to use heuristics to work around this, but
   it seems like a red flag to me, especially if authors use aria-label
   instead of aria-labelledby (which makes it harder to heuristically squelch
   duplication).

Thanks!

Jamie



On Tue, Sep 27, 2016 at 1:56 AM, Richard Schwerdtfeger 
wrote:

> Jamie,
>
> Here is the Digital Publishing ARIA module: http://rawgit.com/w3c/aria/
> master/aria/dpub.html
>
> Please review the IA2 mappings for the digital publishing semantics for
> ARIA. http://rawgit.com/w3c/aria/master/dpub-aam/dpub-aam.html
> Please let me know if you want to create anything new for any of this in
> IA2 or if you see an issue.
>
> There are no new roles specified other than the use of the landmark role
> you added.
>
> The digital publishing industry is using ARIA as the vehicle by which
> publishers will annotate content. The digital publishing ARIA semantics was
> derived by work done by DAISY talking books.
>
> Currently, the mappings have been reviewed and approved by Joanie (ATK)
> and James Craig (Apple).
>
> Thanks,
> Rich
>
> Rich Schwerdtfeger
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] GitHub [was: Reverse relationships]

[James Teh]

Moving to GitHub would also allow us to do cool stuff like set up 
AppVeyor to automatically build a merged idl, proxy dlls and 
documentation for every commit. That way, it'd be possible to get the 
current "master" state of IA2 at any time for experimentation/draft 
implementations.



On 27/09/2016 1:26 AM, Richard Schwerdtfeger wrote:

Hi Janina,
I believe you are still the a11y director at the LF? Can you see any 
reason why IA2 could not be moved to github?

Rich


Rich Schwerdtfeger

- Original message -
From: Alexander Surkov 
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
    To: James Teh 
Cc: IAccessible2 mailing list

Subject: Re: [Accessibility-ia2] Reverse relationships
Date: Fri, Sep 23, 2016 8:00 AM
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 mailto:ja...@nvaccess.org>> wrote:

Hi Alex,

+/** This object is a details for a target object. */
+const WCHAR *const IA2_RELATION_DETAILS = L"details";


1. I think this is the wrong way around. "This" refers to the
object we're pointing *from*. Target means the object we're
pointing *at* (or *to*). Details means the object we're
pointing *at* (the target) provides details for *this* object.

2. I think it'd be good to give a broader description here. I
realise many of the other relations don't, but details versus
describedBy needs some clarification and I think we should be
providing more detail where possible anyway. Perhaps this:

"The target object provides the detailed, extended description
for this object. It provides more detailed information than
would normally be provided using the IA2_RELATION_DESCRIBED_BY
relation. A common use for this relation is in digital
publishing where an extended description needs to be conveyed
in a book that requires structural markup or the embedding of
other technology to provide illustrative content."

+/** The target object is a details for this object. */
+const WCHAR *const IA2_RELATION_DETAILS_FOR = L"detailsFor";


Perhaps this:

"This object provides the detailed, extended description for
the target object. See IA2_RELATION_DETAILS."

+/** This object is an error for a target object. */
+const WCHAR *const IA2_RELATION_ERROR = L"error";


Again, I think these are the wrong way around. I suggest this:

"The target object is the error message for this object."

+/** The target object is an error for this object. */
+const WCHAR *const IA2_RELATION_ERROR_FOR = L"errorFor";


I suggest:

"This object is the error message for the target object."

On another note, is there any chance the Linux Foundation
would let us develop IA2 on GitHub? Having to do code review
by pasting into emails really sucks. Probably not worth the
effort and controversy, but ... ug. :)

Thanks!

Jamie

On 15/09/2016 4:37 AM, Alexander Surkov wrote:

Hi, Jamie.

Here's a changeset [1] for new relations (both direct and
reverse for aria-details and aria-errormessage). Please
review it at your earliest convenience.

Please object if you are not convinced that we have a
valid use case for each relation. I'll be happy to update
the proposal.

Thanks!
Alex.

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306 
www.nvaccess.org <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
<http://www.facebook.com/NVAccess>
Twitter: @NVAccess
SIP: ja...@nvaccess.org <mailto: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] Fwd: figure role backgrounds

[James Teh]

Getting back to the figure role...


In discussing this, I had actually forgotten that Firefox (and Chrome) 
already maps the HTML figure tag to role grouping with xml-roles:figure. 
My apologies. So, there's no controversy here about the role: 
role="figure" should be mapped the same way as HTML figure (role 
grouping and xml-roles:figure).



For reference, there was some controversy about this 5 years ago when 
this decision was made. Back then, Alex and I argued it should be a 
role, but others disagreed for backwards compat reasons. We ended up 
agreeing to use xml-roles. The discussion is on this Mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=658272

Jamie

On 17/09/2016 11:25 AM, Rich Schwerdtfeger wrote:
Then give it a role but don't take a week of people's time arguing 
over it. We have harder problems to work on.


Rich

Sent from my iPhone

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


IMO, xml-roles is a really horrible hack. An object attribute makes 
sense for things like landmarks because a landmark is more like an 
attribute of the element, rather than how it behaves/what it is. I 
argued a long time ago that landmark should have been a specific 
"landmark" attribute, but xml-roles is nevertheless what we have now. 
Relying on this hack even further seems really ugly to me. If figure 
is an important semantic construct, it really should have a role, 
just like heading, etc.



Sent from a mobile device

On 17 Sep. 2016, at 9:33 am, Rich Schwerdtfeger <mailto:richsch...@gmail.com>> wrote:


I have not checked. We have been trying to work with you on this 
first and that has taken well over a week on just figure. We are now 
working with other browser and ATVs now. The current mapping also 
does not require an API change.



Rich

Sent from my iPhone

On Sep 16, 2016, at 8:47 AM, Alexander Surkov 
mailto:surkov.alexan...@gmail.com>> wrote:





On Thu, Sep 15, 2016 at 5:53 PM, Rich Schwerdtfeger 
mailto:richsch...@gmail.com>> 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
<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
mailto:asur...@mozilla.com>> 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
<https://lists.w3.org/Archives/Public/public-aria/2016Sep/0053.html>

On Thu, Sep 15, 2016 at 1:19 AM, Marcos Caceres
mailto:mcace...@mozilla.com>> wrote:

On September 15, 2016 at 2:10:09 PM, Rich Schwerdtfeger
(richsch...@gmail.com <mailto:richsch...@gmail.com>) wrote:

Alex, both Doug and Anna have expressed to you the opinion
 

Re: [Accessibility-ia2] Reverse relationships

[James Teh]

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

[James Teh]

On 8/09/2016 9:22 PM, 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).
I think we'd more likely use it if the user is reviewing a form (rather 
than when the message appears). For example, perhaps error messages 
appear somewhere other than right next to the control. The user might 
want some way to navigate to the control. Honestly, we have no plans to 
implement this, but I think it's a reasonable use case.


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.
I don't think we would skip them. (We don't skip descriptions now 
either.) If they're visible on screen, they should be visible to the 
screen reader user. However, Brett did express a desire to be able to 
access the element referenced by details. Brett, could you perhaps 
provide a use case?


I'll go ahead and review the proposed change as is regardless. I'd still 
like to see a use case for details reverse, though.


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

[James Teh]

To be blunt, part of the reason these thingp have taken so long is that when 
questions are asked, we either get half answers or "well it's in the spec now 
so deal with it". It took me months to finally get a response from you 
concerning errormessage and details which actually addressed my concerns and 
questions with respect and thoroughness. This is yet another reminder of why I 
cannot justify devoting time to spec groups. Maybe you should just maintain the 
IA2 spec yourself, since apparently none of our concerns are actually valid.

Sent from a mobile device

> On 17 Sep. 2016, at 11:25 am, Rich Schwerdtfeger  wrote:
> 
> Then give it a role but don't take a week of people's time arguing over it. 
> We have harder problems to work on.
> 
> Rich
> 
> Sent from my iPhone
> 
>> On Sep 16, 2016, at 8:00 PM, James Teh  wrote:
>> 
>> IMO, xml-roles is a really horrible hack. An object attribute makes sense 
>> for things like landmarks because a landmark is more like an attribute of 
>> the element, rather than how it behaves/what it is. I argued a long time ago 
>> that landmark should have been a specific "landmark" attribute, but 
>> xml-roles is nevertheless what we have now. Relying on this hack even 
>> further seems really ugly to me. If figure is an important semantic 
>> construct, it really should have a role, just like heading, etc.
>> 
>> 
>> Sent from a mobile device
>> 
>>> On 17 Sep. 2016, at 9:33 am, Rich Schwerdtfeger  
>>> wrote:
>>> 
>>> I have not checked. We have been trying to work with you on this first and 
>>> that has taken well over a week on just figure. We are now working with 
>>> other browser and ATVs now. The current mapping also does not require an 
>>> API change.
>>> 
>>> 
>>> Rich
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Sep 16, 2016, at 8:47 AM, Alexander Surkov  
>>>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> 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 accessibl

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

[James Teh]

IMO, xml-roles is a really horrible hack. An object attribute makes sense for 
things like landmarks because a landmark is more like an attribute of the 
element, rather than how it behaves/what it is. I argued a long time ago that 
landmark should have been a specific "landmark" attribute, but xml-roles is 
nevertheless what we have now. Relying on this hack even further seems really 
ugly to me. If figure is an important semantic construct, it really should have 
a role, just like heading, etc.


Sent from a mobile device

> On 17 Sep. 2016, at 9:33 am, Rich Schwerdtfeger  wrote:
> 
> I have not checked. We have been trying to work with you on this first and 
> that has taken well over a week on just figure. We are now working with other 
> browser and ATVs now. The current mapping also does not require an API change.
> 
> 
> Rich
> 
> Sent from my iPhone
> 
>> On Sep 16, 2016, at 8:47 AM, Alexander Surkov  
>> wrote:
>> 
>> 
>> 
>>> 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
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] HTML placeholder attribute

[James Teh]

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-group.com>__

*From:*Alexander Surkov [mailto:surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>]
*Sent:* Tuesday, September 13, 2016 1:52 PM
*To:* Brett Lewis mailto:ble...@vfo-group.com>>; James Teh mailto:ja...@nvaccess.org>>
*Cc:* accessibility-...@lists.linux-foundation.org
<mailto: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
<https://w3c.github.io/aria/html-aam/html-aam.html>
[2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
<http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html>
[3] https://w3c.github.io/aria/accname-aam/accname-aam.html
<https://w3c.github.io/aria/accname-aam/accname-aam.html>
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817
<https://bugzilla.mozilla.org/show_bug.cgi?id=545817>

On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis mailto:ble...@vfo-group.com>> wrote:

Hi All:

I have been looking at how the HTML placeholder attribute is
supported by IA2.

According to the HTML accessibility API mappings at:
https://www.w3.org/TR/html-aam-1.0/
<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
<http://w3c.github.io/aria/core-aam/core-aam.html>

The aria-placeholder is mapped to an Ia2 object attribute of
placeholder.

  

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

[James Teh]

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.



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



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 mailto:ja...@nvaccess.org>> wrote:

To clarify, I'm concerned about aria-errormessage here. For
aria-details, we wouldn't be trying to report the information
as one chunk. Instead, the user would perform a command to
navigate to the details, at which point they would browse it
like they browse any other content.

For aria-errormessage, the use case I'm concerned about is
when the user focuses an aria-invalid element with
aria-errormessage. In that case, we need to report the
aria-errormessage content as one chunk. Because this is focus
handling, we don't use the buffer for this. There may not even
be a buffer in this case, since we don't need a buffer in,
say, an ARIA role="application".


Jamie
On 8/09/2016 2:15 AM, Alexander Surkov wrote:

Shouldn't it be same speed as walking the virtual buffer? I
assume aria-details may contain complex content, for
examplePythagorean Theorem from [1], that may be not suitable
for stringification in general.


[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
<https://www.w3.org/TR/wai-aria-1.1/#aria-details>
On Tue, Sep 6, 2016 at 11:31 PM, James Teh
mailto:ja...@nvaccess.org>> wrote:

That doesn't solve the need to walk the tree to gather
the error message, which is the real problem.

On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:

I think Dominic's suggestion on an interface tester with
bit flags works well.
    Rich


Rich Schwerdtfeger

- Original message -
From: James Teh 
<mailto:ja...@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>,
ble...@freedomscientific.com
<mailto:ble...@freedomscientific.com>,
jdi...@igalia.com <mailto:jdi...@igalia.com>
Cc: accessibility-...@lists.linux-foundation.org
<mailto: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
o

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

[James Teh]

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 examplePythagorean 
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 <mailto:ja...@nvaccess.org>> wrote:


That doesn't solve the need to walk the tree to gather the error
message, which is the real problem.


On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:

I think Dominic's suggestion on an interface tester with bit
flags works well.
Rich


Rich Schwerdtfeger

    - Original message -
From: James Teh  <mailto:ja...@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>,
ble...@freedomscientific.com
<mailto:ble...@freedomscientific.com>, jdi...@igalia.com
<mailto:jdi...@igalia.com>
Cc: accessibility-...@lists.linux-foundation.org
<mailto: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 rel

Re: [Accessibility-ia2] Reverse relationships

[James Teh]

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 mailto:ble...@vfo-group.com>> wrote:

Hi,

Is that documented somewhere?

I read through the information on error and I don’t see
anything about AT skipping error messages if encountering them
while reading through the virtual buffer.

Have I misunderstood something?

Thanks,

Brett

*Brett Lewis*

*VFO*| Software Engineer

11800 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-group.com>

*From:*Alexander Surkov [mailto:surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>]
*Sent:* Wednesday, September 07, 2016 8:02 AM
*To:* Brett Lewis mailto:ble...@vfo-group.com>>
*Cc:* Richard Schwerdtfeger mailto:sch...@us.ibm.com>>; ja...@nvaccess.org
<mailto:ja...@nvaccess.org>; jdi...@igalia.com
<mailto:jdi...@igalia.com>;
accessibility-...@lists.linux-foundation.org
<mailto: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
mailto:ble...@vfo-group.com>> wrote:

Hi Rich,

I think we do need the reverse relationships.

Web authors can place the error/details anywhere on the
page and there doesn’t seem to be any simple way for the
user to determine what element the error message or
details applies to without such a reverse relation.

Brett

*Brett Lewis*

*VFO*| Software Engineer

11800 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-group.com>

*From:*Richard Schwerdtfeger [mailto:sch...@us.ibm.com
<mailto:sch...@us.ibm.com>]
*Sent:* Tuesday, September 06, 2016 12:57 PM
*To:* ja...@nvaccess.org <mailto:ja...@nvaccess.org>;
surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>; Brett Lewis
mailto:ble...@vfo-group.com>>;
jdi...@igalia.com <mailto:jdi...@igalia.com>
*Cc:* accessibility-...@lists.linux-foundation.org
<mailto:accessibility-...@lists.linux-foundation.org>
*Subject:* Reverse relationships

We need agreement:

    Should the error message and details relationships have
reverse mappings?

Rich



Rich Schwerdtfeger




--

Re: [Accessibility-ia2] Reverse relationships

[James Teh]

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 
mailto:sch...@us.ibm.com>> 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 mailto:ja...@nvaccess.org>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>,
ble...@freedomscientific.com
<mailto:ble...@freedomscientific.com>, jdi...@igalia.com
<mailto:jdi...@igalia.com>
Cc: accessibility-...@lists.linux-foundation.org
<mailto: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 <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org>


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
<mailto: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] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[James Teh]

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 <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org>




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

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

[James Teh]

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

[James Teh]

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

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

[James Teh]

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

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

Re: [Accessibility-ia2] Form role mapping

[James Teh]

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

[James Teh]

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 <mailto:ja...@nvaccess.org>> wrote:


If you believe that role="form" has no semantic value other than 
being a landmark, then let's go ahead and map it to 
IA2_ROLE_LANDMARK. On the other hand, the HTML form tag *does* have 
semantic value other than being a landmark, so I'd argue it should be 
IA2_ROLE_FORM.



On 24/08/2016 5:22 AM, Rich Schwerdtfeger wrote:
We are not asking that IA2_ROLE_FORM be deprecated altogether. Even 
with ARIA we have some attributes that re deprecated but that is 
meant so that there will be a replacement solution. An example is 
the drag and drop aria properties. For ARIA browser conformance 
testing to exit Candidate Recommendation we will be testing for 
IA2_ROLE_LANDMARK on form roles.


Rich Schwerdtfeger




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


On 11/08/2016 2:58 AM, Alexander Surkov wrote:

1) adding IA2_ROLE_LANDMARK and

Yes.


2) deprecating IA2_ROLE_FORM?
I'd argue that there is more semantic value in a "form" than just 
the fact that it is a landmark. This probably doesn't apply to ARIA 
(at least for now), since role="form" is defined as only a 
landmark. However, I'd argue it does apply to the HTML form tag. 
So, I'm fine t not use IA2_ROLE_FORM for ARIA role="form", but I'm 
dubious about deprecating it altogether, including for the HTML 
form tag.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org <http://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 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 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

[James Teh]

Hi Rich,


On 24/08/2016 5:14 AM, Richard Schwerdtfeger wrote:
1.There is only one method in each platform to place a description. If 
you have describedby and errormessage relationships which wins?

Concatenate, which brings us to:

2. We cannot guarantee that concatenating them both into one big 
description will make sense to the user as they were not designed to 
work that way. Also, the user might want not want to listen to them 
both together.
If the field is invalid, we're going to read the error message anyway 
and it's going to be read as well as the description and any other info. 
The practical upshot is that we end up with the same result as 
concatenation.


3. Error messages are typically created as alerts as they pop up and 
need to be spoken. So, the user will hear them. The issue is which one 
belongs to which form element.
When an invalid form element gets focus, I'm guessing it makes sense for 
the user to receive the error message. That requires it to be stringified.


4. We don't want to have the user agent have to stringify the text 
either for performance reasons.
It's more performant for a user agent to stringify than it is for an AT. 
Also, user agents are already stringifying aria-labelledby, 
aria-describedby, name from content, etc., so that argument doesn't 
really hold.


So, I would not want you to stringify the error text. The only times 
you will need to provide access to the error message is when you:

1. Have an invalid element (aria-invalid)
At which point we need to stringify it. I'm only suggesting that it be 
stringified by the UA if all conditions are met; invalid, visible, etc.

2. An error message is provided.
At which point we also need to stringify it, but in fairness, this will 
probably be an alert anyway, so I'm less worried about this one.


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] Fwd: IA2 Role Landmark

[James Teh]

   |+  /** 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 <mailto:ja...@nvaccess.org>> wrote:


On 11/08/2016 2:58 AM, Alexander Surkov wrote:

1) adding IA2_ROLE_LANDMARK and

Yes.

2) deprecating IA2_ROLE_FORM?

I'd argue that there is more semantic value in a "form" than just
the fact that it is a landmark. This probably doesn't apply to
ARIA (at least for now), since role="form" is defined as only a
landmark. However, I'd argue it does apply to the HTML form tag.
So, I'm fine t not use IA2_ROLE_FORM for ARIA role="form", but I'm
dubious about deprecating it altogether, including for the HTML
form tag.
Jamie


-- 
James Teh

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




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

[James Teh]

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 <mailto:ja...@nvaccess.org>> wrote:


On 11/08/2016 2:58 AM, Alexander Surkov wrote:

1) adding IA2_ROLE_LANDMARK and

Yes.


2) deprecating IA2_ROLE_FORM?
I'd argue that there is more semantic value in a "form" than just the 
fact that it is a landmark. This probably doesn't apply to ARIA (at 
least for now), since role="form" is defined as only a landmark. 
However, I'd argue it does apply to the HTML form tag. So, I'm fine t 
not use IA2_ROLE_FORM for ARIA role="form", but I'm dubious about 
deprecating it altogether, including for the HTML form tag.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org <http://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 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

[James Teh]

Hi Rich,


If it's not being stringified, IMO, it doesn't make sense to use 
describedBy because describedBy should all be stringified in 
description. My question is why it can't be stringified. You say it 
can't be stringified because:


1. "the content must be visible": That's not a reason not to stringify. 
Describedby can also be visible, yet that never prevented it from being 
stringified.


2. "it will often have content in it, including links, that the user may 
need to navigate to to get help about the error": That could also be 
true for describedby, yet again, that wasn't cited as a reason not to 
stringify it. This argument is problematic anyway because a user won't 
be able to get to those links unless they choose to *review* the error 
message, but the error message has to be spoken in the first place in 
order for a user to know about the error. Reporting the error message 
initially is problematic because now the AT has to stringify the message 
itself, which could be a massive perf hit.



Jamie


On 22/08/2016 11:03 AM, Richard Schwerdtfeger wrote:

Hi James,
If you wanted to reuse the existing description relationships (with a 
separate description relationship instance) and place an object 
attribute on the error message target to indicate that it is an error 
message I think that makes perfect sense. It just can't be 
stringified. However, the errormessage is not to be stringified as the 
content must be visible and it will often have content in it, 
including links, that the user may need to navigate to to get help 
about the error. The aria referenced error messages are all required 
to be visible to apply the relatinship.



Rich Schwerdtfeger

- Original message -
From: James Teh 
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: accessibility-ia2@lists.linuxfoundation.org,
jdi...@igalia.com, surkov.alexan...@gmail.com
Subject: Re: aria-details and aria-errormessage mapping
Date: Sun, Aug 21, 2016 7:46 PM

Hi Rich,

Thanks for the clear explanations; I really do appreciate it. Part
of the confusion here is that I've unintentionally conflated
aria-details with aria-errormessage.

Regarding aria-details, what you say absolutely makes sense. Given
that, reading the details automatically as a simple message
doesn't make sense anyway. Instead, we'd report their presence and
let the user act, just as we do for longdesc now.

However, this same logic does not apply to errormessage. From an
author perspective, I follow that we don't want error messages
"stomping" on describedby. However, from an accessibility client
perspective, I still don't see the difference. They could still be
exposed as part of the description string if they're visible.
Aside from being simpler, that would also be better for
performance, since an AT doesn't then have to crawl the tree
"stringifying" the error messages itself. Can you please explain
why this approach doesn't work? Again, please note that I'm
talking about the accessibility API mapping, *not* the ARIA
attributes; I understand why errormessage and describedby are
separate ARIA attributes for authors.


Thanks.

Jamie
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:

>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.
James,
I appreciate your willingness to work with us on this. However,
let me provide you with the full picture.
1. Extended descriptions, referenced by aria-details was
requested by the digital publishing industry. The extended
description can have all kinds of markup in it and not just HTML:
ChemML, MathML, SVG drawings, etc. It is intended as an extended,
and sometimes alternative content to better illustrate what is
b

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

[James Teh]

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


Rich Schwerdtfeger

- Original message -
From: Alexander Surkov 
<mailto:surkov.alexan...@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "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>
Subject: Re: aria-details and aria-errormessage mapping
Date: Fri, Aug 12, 2016 7:42 PM
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

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

[James Teh]

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

[James Teh]

Hi.


I've already stated my view on this and asked several questions, but it 
seems key decisions have already been made, despite a lack of 
clarification around the concerns I've raised. Given that this has 
basically become a circular time sink of an argument, I'll provide a 
final summary of my thoughts.


1. With regard to stringification, I still haven't seen a single solid 
justification for why errormessage and details are different to 
description from a user perspective. It's been argued that users should 
be able to get to the content and read it in its full semantic glory, 
but no one has pointed out a use case for why that is actually necessary 
for, say, an error message. Surely, the desired UX for a screen reader 
is that it should read the error message when it appears, not force the 
user to press some key to jump there and review it. If we want to read 
the message, we need to stringify it... and crawling the tree to 
stringify it ourselves is going to be a hideous perf problem.
2. Having errormessage/details as completely separate concepts from 
description means an AT now has two more things it has to fetch for 
*every single object that gets focus*. This is yet another perf problem.
3. That said, since the no description/no stringification decision has 
already been made (despite the concerns above which I raised months 
ago), relations is the only mapping that doesn't violate the spec.
4. Since we're not stringifying as part of description, it does not make 
sense to map these to the describedBy relation. Thus, we need two new 
relations.
5. Reverse relations may well be useful in the future. However, if 
they're a potential perf problem, I agree it makes sense to wait until 
we have a use case, so long as implementers accept that this use case 
may one day arise.


Thanks,
Jamie

On 19/08/2016 7:21 AM, Richard Schwerdtfeger wrote:
We *cannot* map aria-errormessage or aria-details to a string 
description. That is absolutely prohibited in the aria specification. 
It is not to be stringified. Neither is aria-details. Also, in the 
aria spec. if aria-details and aria-describedby cannot be mapped 
separately aria-details takes precedence.
These are intended to be references so that we can also get access to 
the structural markup.
Now, if you are going to overload the description relationships we 
need something on the target that indicates they are an error or an 
extended description. We need to have the distinctions. Object 
attributes are an option.

Rich


Rich Schwerdtfeger

- Original message -
From: Alexander Surkov 
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org"
, James Teh
, Joanmarie Diggs 
Subject: Re: aria-details and aria-errormessage mapping
Date: Fri, Aug 12, 2016 7:42 PM
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
mailto:sch...@us.ibm.com>> wrote:

Yes, we heard. So, we need to be able to differentiate an
associated error message from a help descriptions. So, you
could have a second aria-details relationship in the list of
relationships as it would not be stringified (a necessity),
BUT you would need to put something on the target ID container
to indicate to the AT that it is an error message. Otherwise
you need a different relationship. If you are not having
reverse relationships and AT vendors would provide a mechanism
to go back to the element that was invalid then you would be
fine. The use cases we have seen in practices is that multiple
form elements become invalid and each has an associated popup
error message.
We cannot mix descriptions and error messages and the error
messages must be visible to all users to be mapped.
Rich


Rich Schwerdtfeger

- Original message -
From: Alexander Surkov mailto:surkov.alexan...@gmail.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>"

Re: [Accessibility-ia2] ARIA feed role

[James Teh]

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 <mailto:jdi...@igalia.com>> wrote:


Hey Alex.

On 08/10/2016 08:27 AM, Alexander Surkov wrote:

> 1) IA2_ROLE_FEED

Piñeiro might kill me if I tell him I need a new role in ATK. ;)
But if
we absolutely need one for IA2, I can pursue that. However:

> 2) ROLE_SYSTEM_GROUPING with xml-roles='feed'

Is what we want for ATK (i.e. ATK_ROLE_PANEL). Because a list whose
children are not listitem elements is confusing. You have to
descend the
accessibility tree just in case there are some listitems there.
And you
still may not find them in the end.

> 3) ROLE_SYSTEM_LIST with xml-roles='feed'

No thank you.

> Joanie, how have ATK approached to this?

ATK_ROLE_PANEL as indicated above. But Rich only asked for my mappings
recently and I've not actually done anything specific in Orca for the
feed role. So as long as you don't want to make it a list, I'm willing
to discuss an alternative mapping if doing so is helpful.

--joanie




--
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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

On 18/04/2016 7:02 AM, Rich Schwerdtfeger wrote:

Field descriptions are used by more than error messages.
I don't think anyone is debating that. The question is whether 
description could be used for *both*.


In fact, the reason that described by was first used was to remove a 
hack that the SSA had where they were encoding help information about 
form elements to users. So, what you are suggesting is stomping on the 
help information to expose the error information. We are also finding 
that in one of the Federal agencies that people with short term memory 
loss are using the descriptions with a screen reader as the forget 
what the purpose of the form fields and other forms of input are for. 
So, then you stomp on it with an error message and they you want to 
know what you were supposed to input into the field and it is gone. 
This information MUST be separate.
Both pieces of information must be presented, yes, but this isn't 
incompatible with exposure in description. You simply expose the error 
message first in the description.


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


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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

1. If error message were mapped to description in a11y APIs, the user 
agent can choose to expose it first and only when aria-invalid is true.
2. aria-invalid communicates the state of "urgency". For example, NVDA 
says "invalid entry". I don't think screen readers should provide an 
additional indication for an error message, as that would be redundant, 
but that's an implementation detail, not a spec detail.
3. It occurred to me that one possible annoyance with error message 
being mapped to description is that if both were present, a change in 
one might cause both to be read.
4. We might be able to mitigate the performance concern using the 
invalid state; i.e. we only need to check for error message if invalid 
is set. Joanie, thoughts?


Jamie

On 14/04/2016 7:01 AM, Joseph Scheuhammer wrote:

On 2016-04-13 11:46 AM, Matt King wrote:

When aria-errormessage was first discussed, my understanding was that the 
purpose is to distinguish an error message from a description so that assistive 
technologies would have the option to give it special treatment.

Is there more to it than that?

Aria-errormessage is tied to aria-invalid.  The error message is
relevant only when the input is invalid.  In contrast, descriptions have
no specific dependency on validity.

Based on that, the error message is presented only when the input is
invalid.  For a sighted user, the error message is not rendered unless
or until the user has input invalid information.  At that point the
error message is shown near or "attached" to the invalid input.  If the
user corrects the input, the error message vanishes, thereby providing
reinforcement that the error has been corrected.  On the other hand, the
description is presented on demand -- for example, as a tooltip when the
user mouses over the control.  A corollary is that the error message
conveys a sense of urgency or obligation -- something needs to be fixed
-- whereas the description does not.



--
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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

Hey Joanie, all.

Let me try to summarise this mess from my perspective.

1. When you made your initial proposal (description relationships plus 
object attribute), I agreed. You clearly don't see them as fundamentally 
different.
2. However, I noted that if it's being exposed via description 
relationships, it follows that it should also be exposed as part of the 
calculated description text.
3. At this point, it became clear that several people (most notably 
Rich) believe that error messages are fundamentally different to 
descriptions and were thus against (2).

4. If we aren't going to do (2), IMO, (1) doesn't make sense.
5. It's also clear that there is significant disagreement amongst spec 
people as to whether error messages are fundamentally different or not; 
(1) versus (3). That's a major alarm bell for me. IMO, if ARIA and 
accessibility API disagree on this, the whole idea is broken and needs 
to be reconsidered from the ground up.
6. My suggested path forward from here is probably to do (1) and (2), 
despite the objections in (3). We can always change that decision later, 
since this approach is backwards compatible.


Thanks,
Jamie

On 12/04/2016 11:47 PM, Joanmarie Diggs wrote:

Hey Jamie, all.

FWIW, I had proposed exposing it via the existing description-related
relationships plus an object attribute:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002001.html

And I indicated that I didn't have strong feelings either way about
whether or not the description was included as part of the alternative
text calculation:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002011.html

In other words, I personally do not see it as fundamentally different.
Mind you, knowing that something is an error message might prove handy,
hence my suggestion of an object attribute on the element that contains
the error message.

I don't like to take performance hits any more than you do. If you feel
like this approach will result in a performance hit, then we should
rethink things.

All of that said Where I myself am is that we need to map this new
ARIA feature. And we're trying to get ARIA 1.1 locked down. Given that,
along with the fact that it is seen as desirable that we keep our
platforms aligned whenever possible, what I want is *some* mapping. :) I
tossed out the new relation type because I got the impression that my
original proposal was not seen as acceptable, and because you suggested
a new relation type:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002019.html

--joanie

On 04/11/2016 08:18 PM, James Teh wrote:

On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:

If there's sufficient belief that errormessage is inherently different

FWIW, I don't believe this personally--I've not seen a single argument
that I wasn't able to defeat--but it seems like this decision has
already been made in ARIA. Certainly, NVDA will just be merging it into
description internally. What I will say is if ARIA views it as being
fundamentally different (as misguided as I think this is), it seems
problematic if the accessibility APIs merge it.

That said, one nasty problem with an additional API or relation is that
we have to call/crawl that additional thing for *every* accessible just
to find out whether it has an error message. That's kinda ugly from a
performance perspective; we hurt performance everywhere just to support
aria-errormessage. Still, I guess this is the best we can have given the
majority opinion that it is so fundamentally different.

I'm happy with the names you proposed.

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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:

If there's sufficient belief that errormessage is inherently different
FWIW, I don't believe this personally--I've not seen a single argument 
that I wasn't able to defeat--but it seems like this decision has 
already been made in ARIA. Certainly, NVDA will just be merging it into 
description internally. What I will say is if ARIA views it as being 
fundamentally different (as misguided as I think this is), it seems 
problematic if the accessibility APIs merge it.


That said, one nasty problem with an additional API or relation is that 
we have to call/crawl that additional thing for *every* accessible just 
to find out whether it has an error message. That's kinda ugly from a 
performance perspective; we hurt performance everywhere just to support 
aria-errormessage. Still, I guess this is the best we can have given the 
majority opinion that it is so fundamentally different.


I'm happy with the names you proposed.

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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

On 8/03/2016 8:53 AM, Richard Schwerdtfeger wrote:
Furthermore, the error message may have links to help information in 
them. Often these are live region or alerts that pop up in the middle 
of the page.
As I noted before, this could also be true for descriptions. And even if 
it's more true for error messages for some reason, this isn't going to 
affect most AT in any way. If the error message is just reported to the 
user when it appears, a user can't navigate to links therein unless they 
use their cursor, in which case whether it is a separate relationship is 
completely irrelevant.


Also, there may be hidden help information in forms on the form 
elements. You don't want to mix that with error messages. It is also 
important that designers check to make sure they have mapped the 
actual error messages to the invalid form elements. This can be 
verified by having it in a separate relationship.
That might be a justification for making it separate in ARIA, but not 
for exposing it separately via accessibility APIs. I haven't seen one 
undefeated argument yet as to why an AT needs to have it exposed 
separately from description.


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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

On 2/03/2016 12:13 AM, Joanmarie Diggs wrote:

If you really do want errormessage to be treated as an entirely
separate thing, then I have to change my position on this: we need a
new relation and new events.

Really? Why can't we map it via described-by/description-for and then
use an object attribute to check if the descriptive element is an object
attribute?
Everyone else is saying that errormessage is inherently different to 
description. If that really is how it's meant to be according to the 
ARIA spec (I disagree, but that's not relevant here), then mapping it to 
description (even with an attribute) is a big hack. You can't have it 
both ways; it's either just a specialisation of description or it's not. 
Several people now say it's not the former, so it must be the latter. 
And if it *is* the former, then it should be included as part of the 
description text as well.


FWIW, I don't like this whle thing at all, but it seems wrong to me that 
the ARIA spec says it's not at all a description and the a11y specs say 
it is. Personally, I think the ARIA spec *should* treat it as just an 
extension of description, but I've already made that point and it 
doesn't seem popular.


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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

The same could apply to descriptions (e.g. a description could include a link 
to more info about how to fill in the field), but that's never been a factor 
before. Also, even if you believe this is more likely with errormessage for 
some reason, I'm guessing you still want AT to report the message when it 
appears and/or the control gets focus, in which case it can only be rendered as 
a string anyway.

Sent from a mobile device

> On 25 Feb 2016, at 9:33 AM, Richard Schwerdtfeger  
> wrote:
> 
> Error messages may have additional content in there that needs greater 
> semantic structure. For example, what if the error message had a link to a 
> online help area about the topic. Converting it to a string would not work.
> 
> Rich
>> On Feb 23, 2016, at 5:20 PM, Joanmarie Diggs  wrote:
>> 
>> Hey Jamie.
>> 
>> Yeah, we have a description property which is a string. Right now, I
>> don't have a strong feeling either way about whether aria-errormessage's
>> text belongs as part of that value. So if you think it should be there
>> in addition to exposed via the relationship pair, I don't mind.
>> 
>> --joanie
>> 
>>> On 02/23/2016 06:03 PM, James Teh wrote:
>>> Sounds great. I'm happy with this mapping.
>>> 
>>> Would this message be included in the concatenated description string
>>> for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2),
>>> you can call the accDescription property and it provides the description
>>> as a string. Right now, that would include the text of anything listed
>>> in aria-describedby. I think it *should* include the error message myself.
>>> 
>>> Jamie
>>> 
>>>> On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:
>>>> Hey all.
>>>> 
>>>> We need to map aria-errormessage on the various platforms, including
>>>> ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
>>>> homogeneity, I'll toss out what I was thinking for my platform for
>>>> consideration by IA2 folks.
>>>> 
>>>> Proposal: Connect the message to the element with the error via the
>>>> RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
>>>> "errormessage" as an object attribute.
>>>> 
>>>> Rationale:
>>>> 
>>>> 1. An error message provides descriptive information about an object.
>>>> 
>>>> 2. Exposure via a relation eliminates the need to tree dive to find
>>>>   the error.
>>>> 
>>>> 3. Accessible relations can have multiple targets, so this exposure
>>>>   does not stomp on a non-error description while at the same time
>>>>   eliminating the need for each platform to create a new relation
>>>>   type(s).
>>>> 
>>>> 4. The object attribute is needed to identify which target (if any)
>>>>   is an error message.
>>>> 
>>>> Thoughts?
>>>> --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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

I thought aria-describedby could refer to multiple nodes. As such, I don't 
follow why authors were "stuck" when they wanted both an error message and a 
description. They could just put both in aria-describedby.

If you really do want errormessage to be treated as an entirely separate thing, 
then I have to change my position on this: we need a new relation and new 
events. If it's really such a new and separate thing, we don't have to worry 
about existing AT not getting the benefit.

Sent from a mobile device

> On 25 Feb 2016, at 1:50 AM, Joseph Scheuhammer  wrote:
> 
> Part of the rationale for introducing aria-errormessage was that authors were 
> already using aria-describedby for the error message, but were stuck when 
> they wanted to provide a description separate from the error message. Thus, a 
> reason for introducing aria-errormessage was to distinguish it from the 
> description.  Consider also that error messages are transient, whereas 
> descriptions are not.
> 
> Conflating the two at the AAPI level is counterproductive.
> 
>> On 2016-02-23 6:20 PM, Joanmarie Diggs wrote:
>> Hey Jamie.
>> 
>> Yeah, we have a description property which is a string. Right now, I
>> don't have a strong feeling either way about whether aria-errormessage's
>> text belongs as part of that value. So if you think it should be there
>> in addition to exposed via the relationship pair, I don't mind.
>> 
>> --joanie
>> 
>>> On 02/23/2016 06:03 PM, James Teh wrote:
>>> >Sounds great. I'm happy with this mapping.
>>> >
>>> >Would this message be included in the concatenated description string
>>> >for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2),
>>> >you can call the accDescription property and it provides the description
>>> >as a string. Right now, that would include the text of anything listed
>>> >in aria-describedby. I think it*should*  include the error message myself.
>>> >
>>> >Jamie
>>> >
>>> >On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:
>>>> >>Hey all.
>>>> >>
>>>> >>We need to map aria-errormessage on the various platforms, including
>>>> >>ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
>>>> >>homogeneity, I'll toss out what I was thinking for my platform for
>>>> >>consideration by IA2 folks.
>>>> >>
>>>> >>Proposal: Connect the message to the element with the error via the
>>>> >>RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
>>>> >>"errormessage" as an object attribute.
>>>> >>
>>>> >>Rationale:
>>>> >>
>>>> >>1. An error message provides descriptive information about an object.
>>>> >>
>>>> >>2. Exposure via a relation eliminates the need to tree dive to find
>>>> >> the error.
>>>> >>
>>>> >>3. Accessible relations can have multiple targets, so this exposure
>>>> >> does not stomp on a non-error description while at the same time
>>>> >> eliminating the need for each platform to create a new relation
>>>> >> type(s).
>>>> >>
>>>> >>4. The object attribute is needed to identify which target (if any)
>>>> >> is an error message.
>>>> >>
>>>> >>Thoughts?
>>>> >>--joanie
>>>> >>___
>>>> >>Accessibility-ia2 mailing list
>>>> >>Accessibility-ia2@lists.linuxfoundation.org
>>>> >>https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>>> >
> 
> 
> -- 
> 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] Collections iface? (Re: IA2 Role Landmark)

[James Teh]

Hey Joanie,

IMO, AT-SPI2 is a better place to implement a collections interface, 
even if it needs some enhancement. This way, all servers benefit without 
every server having to do its own implementation. That would mean a lot 
of duplication plus more room for error and inconsistency. The core 
framework (e.g. AT-SPI2) should be doing the filtering in the server 
process, but at the end of the day, it's just filtering based on the raw 
stuff that's already exposed by the API.


The reason IA2 doesn't have anything like this is that IA2 doesn't have 
an equivalent to AT-SPI2 at all; i.e. it's just raw API calls. This is 
because in the Windows world, we have this horrible thing called 
in-process injection, and it's just become accepted that AT vendors will 
do all of this horrible stuff themselves. Since NVDA is the only screen 
reader that seems to care about doing this more elegantly out-of-process 
(and we already have in-process code as much as it pains me), it's 
probably not worth doing for IA2.


On the other hand, UI Automation does as I describe. The raw interfaces 
just expose properties and methods, but the UI Automation Core handles 
cross-process searching and caching. It needs some significant 
enhancement--right now, it's hopelessly unequipped to handle a web 
browser, which is why we have so many problems with Edge and is 
something I'm harassing Microsoft to fix--but in theory, I believe it's 
probably the more elegant way to do things.


Jamie

On 24/02/2016 9:30 AM, Joanmarie Diggs wrote:

Hey Jamie, and everyone but the ARIA list which I've just un-CCed as I'm
going down a tangent.  More below.

On 02/23/2016 05:50 PM, James Teh wrote:

We don't have a collections interface for IA2,

There's not one in ATK either. And the API for what we have in AT-SPI2
sucks dirty socks IMHO. Mind you, it's way better than doing the tree
dive

Anyhoo, I mention this not to complain, but to suggest that if IA2
wanted a collections interface, I think ATK should also have one, and it
might be nice to come up with an API we both like and which would be
easy for Alex to implement on both platforms.

--joanie



--
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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

Maybe, except that as far as a user is concerned, it is just extra 
descriptive text. Certainly, I don't see a point in handling it 
separately in NVDA as far as configuration goes. The aria-invalid state 
is enough to tell the user that this is an error.


Jamie

On 24/02/2016 10:07 AM, Cynthia Shelly wrote:

I would prefer not to include it in name and description calculation. Too many 
things are getting added to the description, and it makes for a messy user 
experience.

-Original Message-
From: Joanmarie Diggs [mailto:jdi...@igalia.com]
Sent: Tuesday, February 23, 2016 3:20 PM
To: James Teh 
Cc: IA2 List ; ARIA Working Group 

Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

Hey Jamie.

Yeah, we have a description property which is a string. Right now, I don't have 
a strong feeling either way about whether aria-errormessage's text belongs as 
part of that value. So if you think it should be there in addition to exposed 
via the relationship pair, I don't mind.

--joanie

On 02/23/2016 06:03 PM, James Teh wrote:

Sounds great. I'm happy with this mapping.

Would this message be included in the concatenated description string
for an object? I'm not sure if ATK has this, but in MSAA (and thus
IA2), you can call the accDescription property and it provides the
description as a string. Right now, that would include the text of
anything listed in aria-describedby. I think it *should* include the error 
message myself.

Jamie

On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:

Hey all.

We need to map aria-errormessage on the various platforms, including
ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
homogeneity, I'll toss out what I was thinking for my platform for
consideration by IA2 folks.

Proposal: Connect the message to the element with the error via the
RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and
expose "errormessage" as an object attribute.

Rationale:

1. An error message provides descriptive information about an object.

2. Exposure via a relation eliminates the need to tree dive to find
 the error.

3. Accessible relations can have multiple targets, so this exposure
 does not stomp on a non-error description while at the same time
 eliminating the need for each platform to create a new relation
 type(s).

4. The object attribute is needed to identify which target (if any)
 is an error message.

Thoughts?
--joanie
___
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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

[James Teh]

Sounds great. I'm happy with this mapping.

Would this message be included in the concatenated description string 
for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2), 
you can call the accDescription property and it provides the description 
as a string. Right now, that would include the text of anything listed 
in aria-describedby. I think it *should* include the error message myself.


Jamie

On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:

Hey all.

We need to map aria-errormessage on the various platforms, including
ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
homogeneity, I'll toss out what I was thinking for my platform for
consideration by IA2 folks.

Proposal: Connect the message to the element with the error via the
RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
"errormessage" as an object attribute.

Rationale:

1. An error message provides descriptive information about an object.

2. Exposure via a relation eliminates the need to tree dive to find
the error.

3. Accessible relations can have multiple targets, so this exposure
does not stomp on a non-error description while at the same time
eliminating the need for each platform to create a new relation
type(s).

4. The object attribute is needed to identify which target (if any)
is an error message.

Thoughts?
--joanie
___
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

[James Teh]

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] Mapping of aria-kbdshortcuts for ATK/AT-SPI2 and IA2

[James Teh]

Hi Joanie,

This is one of those cases where IA2 and ATK are going to differ. This 
time, it's because MSAA (on which IA2 is based) already has an 
accKeyboardShortcut property 
<https://msdn.microsoft.com/en-us/library/windows/desktop/dd318482%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396> 
which just exposes a keyboard shortcut. I think this lends itself well 
to exposing aria-kbdshortcuts.


Thanks,
Jamie

On 24/02/2016 6:02 AM, Joanmarie Diggs wrote:

Hey all.

We need to come up with mappings for aria-kbdshortcuts for ATK/AT-SPI2
and IA2. And, unlike aria-errormessage, I got nothing (or almost nothing).

When the feature and question of mappings was first raised, I was
thinking it could be mapped via the Action interface. At least in the
case of my platform, that's where keyboard shortcuts are exposed. But
those shortcuts are associated with an action which can be performed by
the Action interface. And that's not the case with aria-kbdshortcuts. As
the spec states:


Adding the aria-kbdshortcuts attribute to an element does not change the
behavior of the user agent by mapping the specified keyboard shortcuts
to the triggering of the element's activation function. It is still up
to the application to implement support for the keyboard shortcuts. The
aria-kbdshortcuts attribute exposes the fact that these shortcuts exist
so that assistive technologies can communicate this information to users.


So if it's exposed via the action interface, we'd have the shortcut and
a name, but we'd have to know (and user agents would have to expose)
that the action might not be something we could actually perform. With
respect to the latter, on the surface it seems easy because, at least on
my platform, atk_action_do_action() returns a boolean reflecting
success. However, in practice, at least some implementors always return
true because they don't want performing an action to be blocking. In
other words, the return value is useless.

So Do we map this property via the Action attribute and just deal
with the fact that we cannot perform actions, or Something else?

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

[James Teh]

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

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

[James Teh]

On 6/01/2016 12:03 PM, Richard Schwerdtfeger wrote:


So, why can't you simply ask for the the first non-empty cell ( a new 
api) in the current column in a given direction. Or the first non 
empty cell in the current row (new api again) in a given direction?


That's what I'm asking for. I think we need to be careful with the term 
non-empty; cells which exist but are "blank" shouldn't be skipped. 
However, I'm guessing you mean non-empty as in "actually exists in the 
tree right now".



Is that it or do you have other use cases?

Dominic seems to suggest that if there isn't a cell in the same column 
in the next row, we shouldn't skip rows. I personally disagree with 
this, but his argument is that a user might not realise there was data 
in other columns in the skipped rows. If we do want to support Dominic's 
request, we'd need to be able to navigate to the next "nearest" cell in 
a given direction; e.g. if navigating by row, the cell returned might 
not be in exactly the same column.


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-colcount and aria-rowcount mapping, again

[James Teh]

Precisely what you're trying to say we need to do: allow for navigation 
other than row + 1 and col + 1. If we have a table which has a cell at 
r1c2 but no cell at r2c2 and the user navigates down by row from r1c2, 
how does an AT find the next appropriate cell? There are two choices 
right now:
1. Keep trying IAccessibleTable2::cellAt with increasing row numbers 
until we find a cell. But what if the next cell is at r1000c2 (which is 
entirely possible with these new ARIA properties)? That'd mean calling 
cellAt 999 times.
2. Use accNavigate to walk through the rows, query the first column in 
each row to get its row number, then use cellAt to get the cell n that 
row in the original column. This does allow us to skip rows which have 
no data at all. However, it's still horrible because:
* There might be interspersed thead/tbody/rowgroup elements, requiring 
hierarchical tree traversal.

* There are still a huge number of calls.

Aside from the complexity and performance horror, it's also difficult 
for implementers to grasp. They look at IA2 and see a table interface, 
but then have to understand that actually, the table interface isn't 
enough to navigate tables by row and column; they might actually have to 
do some insane tree walking to get anything useful.


Things get even worse if you believe an AT should do something other 
than skipping rows if there is no cell in the same column on the next 
non-empty row. Dominic suggests we should just go to the first column. I 
think that is a bad user experience and breaks a user's spatial feel of 
the table. So if we want to move to the next "nearest" cell, now we 
can't even use cellAt any more. We have to walk the children of every 
subsequent row looking for "nearby" coordinates.


Jamie

On 6/01/2016 11:39 AM, Richard Schwerdtfeger wrote:


What are the use cases?


Rich Schwerdtfeger

Inactive hide details for James Teh ---01/05/2016 07:15:27 PM---My 
point is that we don't currently have a way of handling thisJames Teh 
---01/05/2016 07:15:27 PM---My point is that we don't currently have a 
way of handling this decently  with IA2 and that we need


From: James Teh 
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: IAccessible2 mailing list 
, 
accessibility-ia2-boun...@lists.linuxfoundation.org, Dominic Mazzoni 


Date: 01/05/2016 07:15 PM
Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount 
mapping, again






My point is that we don't currently have a way of handling this 
decently with IA2 and that we need new API calls. Saying "just faf 
around with accNavigate and try all sorts of different stuff until you 
find what you want" isn't good enough IMO, not least because it's 
horribly unperformant cross-proc. If we're going to have gaps at the 
start/in the middle of rows, we need some sort of table navigation 
function that can handle different types of navigation. Currently, 
there is no such function.


Jamie

On 6/01/2016 11:00 AM, Richard Schwerdtfeger wrote:


Jamie,

I have to agree with Dominic that you have a lot of different what
ifs for determining where to go when a cell is empty. I think you
need to be able to pass a parameter that asks the browser to go
where you want based on a set of criteria.

For example, So, what if several rows are skipped? When does the
situation become problematic?

What condition do you want to be met?

e.g. a parameter that tells us what to do if an empty cell is
encountered:

GOTO_FIRST_NONEMPTY_ADJACENT_CELL

What I am getting at is what is the algorithm you want the user
agent to follow when an empty cell is encountered. Does it Vary
based on a parameter. Do you want hidden cells to be ignored?


Rich


Rich Schwerdtfeger

Inactive hide details for James Teh ---01/05/2016 04:50:38 PM---On
5/01/2016 7:53 AM, Richard Schwerdtfeger wrote: >James Teh
    ---01/05/2016 04:50:38 PM---On 5/01/2016 7:53 AM, Richard
Schwerdtfeger wrote: >

From: James Teh __ <mailto:ja...@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Dominic Mazzoni
__ <mailto:dmazz...@google.com>
Cc: IAccessible2 mailing list
__
<mailto:accessibility-...@lists.linux-foundation.org>,
_accessibility-ia2-bounces@lists.linuxfoundation.org_
<mailto:accessibility-ia2-boun...@lists.linuxfoundation.org>
Date: 01/05/2016 04:50 PM
Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again




On 5/01/2016 7:53 AM, Richard Schwerdtfeger wrote:

Although it is possible to have 2 cells I don't think this
even close to the norm.
Two cells was just an extreme example to demonstrate the issue.
Th

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

[James Teh]

My point is that we don't currently have a way of handling this decently 
with IA2 and that we need new API calls. Saying "just faf around with 
accNavigate and try all sorts of different stuff until you find what you 
want" isn't good enough IMO, not least because it's horribly 
unperformant cross-proc. If we're going to have gaps at the start/in the 
middle of rows, we need some sort of table navigation function that can 
handle different types of navigation. Currently, there is no such function.


Jamie

On 6/01/2016 11:00 AM, Richard Schwerdtfeger wrote:


Jamie,

I have to agree with Dominic that you have a lot of different what ifs 
for determining where to go when a cell is empty. I think you need to 
be able to pass a parameter that asks the browser to go where you want 
based on a set of criteria.


For example, So, what if several rows are skipped? When does the 
situation become problematic?


What condition do you want to be met?

e.g. a parameter that tells us what to do if an empty cell is encountered:

GOTO_FIRST_NONEMPTY_ADJACENT_CELL

What I am getting at is what is the algorithm you want the user agent 
to follow when an empty cell is encountered. Does it Vary based on a 
parameter. Do you want hidden cells to be ignored?



Rich


Rich Schwerdtfeger

Inactive hide details for James Teh ---01/05/2016 04:50:38 PM---On 
5/01/2016 7:53 AM, Richard Schwerdtfeger wrote: >James Teh 
---01/05/2016 04:50:38 PM---On 5/01/2016 7:53 AM, Richard 
Schwerdtfeger wrote: >


From: James Teh 
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Dominic Mazzoni 

Cc: IAccessible2 mailing list 
, 
accessibility-ia2-boun...@lists.linuxfoundation.org

Date: 01/05/2016 04:50 PM
Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount 
mapping, again






On 5/01/2016 7:53 AM, Richard Schwerdtfeger wrote:


Although it is possible to have 2 cells I don't think this even
close to the norm. 



Two cells was just an extreme example to demonstrate the issue. The 
point is that gaps at the start or middle of a row are problematic.



Why would we we not just have the screen reader ask to go to a row
and column number? 



Because if there is a gap, incrementing row or column by one isn't 
sufficient. It could be 1, 2 or an arbitrary number.



It is not difficult to ask the user agent to navigate to compute
the effective cell to the right and ask for the user agent to
navigate there. 



It's probably always true that navigating to the adjacent cell in the 
next column is as simple as accNavigate with NAVDIR_NEXT. However, 
navigating to the adjacent cell in the next row is not so simple. What 
if several rows are skipped?



We can add a parameter that states to navigate to the first
non-empty cell to the ... or whatever algorithm we choose. 



Add a parameter to what? I think this would require a new function, 
which is what I was suggesting.


Dominic wrote:

Jamie, as an alternative, couldn't the screen reader try
navigating to the next / previous cell using the row, column
index, but if that fails, fall back on DOM navigation?

For example, given a current cell (x, y), if the user wants to go
right - to the next cell in the same row, try (x + 1, y) but if
that's empty, use the accessibility tree to navigate to the next
sibling. 

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.


Similarly, given (x, y) if the user wants to go down - to the same
column in the next row, try (x, y + 1), but if that's empty, use
the accessibility tree to navigate to the next row, 


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.


then try column x in that row, and if that fails, navigate to the
first cell in that row. 

We never want to fall back to the first column like that. If a user 
moves down a row, they expect to move down a row, not down and across 
(excepting column spans).


Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
_www.nvaccess.org_ <http://www.nvaccess.org/>
Facebook: _http://www.facebook.com/NVAccess_
Twitter: @NVAccess
SIP: _jamie@nvaccess.org_ <mailto:ja...@nvaccess.org>




--
James Teh
Execut

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

[James Teh]

On 5/01/2016 7:53 AM, Richard Schwerdtfeger wrote:


Although it is possible to have 2 cells I don't think this even close 
to the norm.


Two cells was just an extreme example to demonstrate the issue. The 
point is that gaps at the start or middle of a row are problematic.


Why would we we not just have the screen reader ask to go to a row and 
column number?


Because if there is a gap, incrementing row or column by one isn't 
sufficient. It could be 1, 2 or an arbitrary number.


It is not difficult to ask the user agent to navigate to compute the 
effective cell to the right and ask for the user agent to navigate there.


It's probably always true that navigating to the adjacent cell in the 
next column is as simple as accNavigate with NAVDIR_NEXT. However, 
navigating to the adjacent cell in the next row is not so simple. What 
if several rows are skipped?


We can add a parameter that states to navigate to the first non-empty 
cell to the ... or whatever algorithm we choose.


Add a parameter to what? I think this would require a new function, 
which is what I was suggesting.


Dominic wrote:
Jamie, as an alternative, couldn't the screen reader try navigating to 
the next / previous cell using the row, column index, but if that 
fails, fall back on DOM navigation?


For example, given a current cell (x, y), if the user wants to go 
right - to the next cell in the same row, try (x + 1, y) but if that's 
empty, use the accessibility tree to navigate to the next sibling.
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.


Similarly, given (x, y) if the user wants to go down - to the same 
column in the next row, try (x, y + 1), but if that's empty, use the 
accessibility tree to navigate to the next row,

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.


then try column x in that row, and if that fails, navigate to the 
first cell in that row.
We never want to fall back to the first column like that. If a user 
moves down a row, they expect to move down a row, not down and across 
(excepting column spans).


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-colcount and aria-rowcount mapping, again

[James Teh]

On 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
Totally agreed that screen readers need to be able to navigate from 
cell to cell and fetch rows at a time. Note that the spec requires the 
numbering to be sequential, so you don't need to worry about that.

When I said sequential, I also meant contiguous; i.e. 1, 2, 3, not 1, 2, 5.


I'd like to point out that in vanilla HTML it's quite common for 
tables to have missing cells already.
Missing cells only towards the end of rows, never in the middle or at 
the start. So, you might not be able to move to the next cell at the end 
of an incomplete row, but that's okay because you've already seen all of 
the cells on that row. Conversely, if there are cells missing at the 
start or in the middle of a row, it may be impossible to get to other 
cells in the row.


Screen readers shouldn't have to do any extra work to deal with most 
such tables because they already need to be able to handle missing 
cells, so this wouldn't be any different.


See above. Start/middle gaps are a problem and I can't even think of a 
good way to handle this. This is why I am probably more for this solution:


The alternative proposal seems to be to export the ARIA attributes 
and/or use group position and have the screen reader announce the ARIA 
row and column indexes but otherwise explore the table from the DOM.


* Screen readers wouldn't be able to jump to a cell by row, column 
index. (JAWS has a keystroke for this now.)

Hmm. That certainly is a problem, yes.

I guess another solution could be to extend IAccessibleTableCell to 
provide a way to get to the next cell in a given direction. I *think* 
that would solve the start/middle gap problem.


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

[James Teh]

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

[James Teh]

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 <mailto:ja...@nvaccess.org>> wrote:


Hi Alex,

The interface/method looks fine. Just one comment on the
documentation:


+ * One of the range points is an anchor, a start of the range,
and another one
+ * is a range end, which typically coincides with the user focus.


I think we need to be careful about the words "start" and "end"
here. In the usual case, anchor will be less than active.
However, if the user is selecting backwards, active will be less
than anchor. Even if active < anchor, I still see the lesser
number as being the "start" of the "range". This is one of the
reasons I preferred start, end and a boolean for the
anchor/active determination, though I realise that seems like a
pointless waste of bytes.

Maybe we could say something like:

The "anchor" is one point of the range and typically remains
constant. The other point is the "active" point, which
typically corresponds to the user's focus or point of
interest. The user moves the active point to expand or
collapse the range. In most cases, anchor is the start of the
range and active is the end. However, when selecting
backwards (e.g. pressing shift+left arrow in a text field),
the start of the range is the active point, as the user moves
this to manipulate the selection.


The other problem is that unless you're dealing with something
like selection, the terms anchor and active don't make a huge
amount of sense, since neither point is the "anchor". I realise
that selection is the primary use case, but it seems like this
range struct is trying to be more generic than this.


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



Jamie

On 4/12/2015 10:57 PM, Alexander Surkov wrote:

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

[1]

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



-- 
James Teh

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




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

[James Teh]

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 <mailto:ja...@nvaccess.org>> wrote:


Hi Alex,

The interface/method looks fine. Just one comment on the
documentation:


+ * One of the range points is an anchor, a start of the range,
and another one
+ * is a range end, which typically coincides with the user focus.


I think we need to be careful about the words "start" and "end"
here. In the usual case, anchor will be less than active. However,
if the user is selecting backwards, active will be less than
anchor. Even if active < anchor, I still see the lesser number as
being the "start" of the "range". This is one of the reasons I
preferred start, end and a boolean for the anchor/active
determination, though I realise that seems like a pointless waste
of bytes.

Maybe we could say something like:

The "anchor" is one point of the range and typically remains
constant. The other point is the "active" point, which
typically corresponds to the user's focus or point of
interest. The user moves the active point to expand or
collapse the range. In most cases, anchor is the start of the
range and active is the end. However, when selecting backwards
(e.g. pressing shift+left arrow in a text field), the start of
the range is the active point, as the user moves this to
manipulate the selection.


The other problem is that unless you're dealing with something
like selection, the terms anchor and active don't make a huge
amount of sense, since neither point is the "anchor". I realise
that selection is the primary use case, but it seems like this
range struct is trying to be more generic than this.


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



Jamie

On 4/12/2015 10:57 PM, Alexander Surkov wrote:

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

    [1]

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



-- 
James Teh

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




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

[James Teh]

On 5/12/2015 6:28 AM, Andres Gonzalez wrote:
In a separate but related note, I was wondering if we really need to 
keep deriving from IAccessible2 and sub-interfaces. I know we did 
interface inheritance from the beginning of IA2, but in my humble 
opinion, that was a design mistake. COM is great for having small, 
independent interfaces, and an object can choose and pick which 
interface to implement. This could be the IA2_Selectable interface.
While I totally agree we should introduce new, non-derived interfaces 
for related methods, I'm against having separate interfaces for single 
methods. We could end up with heaps of little tiny interfaces all with 
one method. Aside from being confusing, this means a lot of 
QueryInterfacing, which means holding a lot of pointers around and a lot 
of pointless cross-proc calls.


No need to revisit or belabor this point if you guys already have 
decided on it, I was just curious about carrying out with this 
interface inheritance and the IAccessibleX_Y naming that doesn’t tell 
anything about what the interface does.
It's certainly true that IAccessibleX_Y doesn't tell you anything about 
the interface. On the other hand, if we end up with a new interface 
every time we add a new method, we could end up with interfaces like 
IA2_method_name_here, which is surely just as bad. As an example, if you 
look at the methods in IAccessible2_2, most of them are unrelated; some 
deal with attributes, some deal with relations, etc. It's pretty 
difficult to come up with interfaces for those that make any real sense 
aside from their method names.


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

[James Teh]

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.


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

[James Teh]

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.


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

[James Teh]

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. :) 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.


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

[James Teh]

On 3/12/2015 8:06 AM, Richard Schwerdtfeger wrote:


This is not always accurate:
"So, it basically maps to aria-activedescendant"
If you have a navigation section with links and you clicked on one to 
load a section in an iframe on the same page you would mark the link 
as aria-current. You would not change aria-current to true on a link 
in the navigation section once you moved back simply because it 
received focus as the current active navigation link is not the 
focused link.


I'm well aware of that. My point is that, according to the text I quoted 
from the IA2 spec, the IA2 active state basically maps to 
aria-activedescendant *right now*. The IA2 active state in its 
*currently documented form* cannot be used for aria-current without 
changing the spec, which obviously requires consultation with all 
stakeholders. The alternative is to implement a new state.


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

[James Teh]

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

On 2/12/2015 6:45 AM, Richard Schwerdtfeger wrote:


http://lists.linux-foundation.org/pipermail/accessibility-ia2/2015-September/001939.html

Alex, why would you not want the active state on non-widgets? For 
example, if you have a list of links in a navigation landmark section 
you do not want to mix focus with active. This is because what is 
active was the last navigation item you activated.


Rich


Rich Schwerdtfeger


___
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] a new method to retrieve the selection

[James Teh]

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

[James Teh]

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

[James Teh]

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.


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


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



-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 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 mapping of aria-current

[James Teh]

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

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


--
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] Fw: ARIA 1.1 feature status aria-rowspan and aria-colspan

[James Teh]

On 5/08/2015 10:59 PM, Alexander Surkov wrote:
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.
One concern with that though is that you can only fetch one attribute at 
a time if you use it, which is nasty for out-proc usage.


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] rowspan and colspan

[James Teh]

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

Re: [Accessibility-ia2] aria-roledescription

[James Teh]

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

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

[James Teh]

On 26/06/2015 7:58 AM, Richard Schwerdtfeger wrote:

You need to implement it as you can't determine how many rows or columns
are in a rich internet application. You need to provide context.
The problem is that this creates broken cases if you're doing anything 
other than application-defined keyboard navigation. If you use screen 
reader commands to move between table cells, the screen reader may not 
be able to find the cell it wants because it isn't available. There's 
currently no way for an AT to tell the application to on-demand load a 
requested table cell.


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-colcount and aria-rowcount mapping

[James Teh]

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.

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-colcount and aria-rowcount mapping

[James Teh]

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

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

[James Teh]

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

Re: [Accessibility-ia2] placeholder mapping

[James Teh]

On 30/04/2015 10:55 AM, Joanmarie Diggs wrote:

if you've already made this choice
for ATK,

FWIW, it was made years ago and by several developers
I still think doing this with descriptions might be better, but I do at 
least follow the reasoning behind this decision. It's worth noting that 
we don't really have placeholder exposure on Windows outside of Firefox. 
Therefore , it's probably simpler to do what ATK is doing.


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

[James Teh]

On 30/04/2015 10:26 AM, Joanmarie Diggs wrote:

Good point. There's an alternative, though: the UA could expose it as a
description only if there is no value. Once there is a value, it isn't
exposed. If the value is cleared, it gets exposed again.

And UAs would also have to emit a signal to indicate the accessible
description has changed. Aside from general principle (notify platforms
of changes), this would be needed for platforms where caching is done to
trigger the cached property to be updated.
Sure. There's already such a signal on Windows, though I don't think 
Gecko actually fires it... :)



And what happens if you have an indecisive form-filler-outer who types a
character, thinks "no", and BackSpaces. Tries again, reconsiders, and
BackSpaces. Should user agents really clear the description, set the
description, clear the description, etc., emitting signals each time?
Well, that's kinda what happens visually, no? The placeholder disappears 
and reappears each time. Arguably, continually exposing the placeholder 
via an object attribute is actually contrary to the UX of a sighted 
user, since a sighted user can't see the placeholder when the field has 
a value.



Regardless, this mapping would be inconsistent with happens on my
platform for both Gtk+ and WebKitGtk. So if it floats your platform's
boat go for it on your platform. Please do not take this approach on mine.
Fair enough. We've tried to keep IA2 and ATK fairly closely synced to 
unify things/make things easier, but if you've already made this choice 
for ATK, changing it there now obviously isn't an option. In that case, 
this discussion is purely academic for you.


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

[James Teh]

On 30/04/2015 3:16 AM, Joanmarie Diggs wrote:

It's possible to have a name and description and placeholder.
True, but it's also possible to have multiple other things which would 
normally get mapped to name or description. That's why we have 
precedence rules. :)



Beyond that, because the placeholder is the displayed text when the
input element lacks a value, an AT might wish to present the placeholder
only when there is not a value. In other words, provide the same
experience sighted users have. In order to do that, the AT needs to know
it's a placeholder. Exposing it as the description -- without also
exposing it as the placeholder -- prevents ATs from being able to do that.
Good point. There's an alternative, though: the UA could expose it as a 
description only if there is no value. Once there is a value, it isn't 
exposed. If the value is cleared, it gets exposed again.


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

[James Teh]

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] 64 bit proxy dll [was: Accessibility-ia2 Digest, Vol 72, Issue 5]

[James Teh]

Hi.

On 17/11/2014 5:24 PM, Rajesh V R wrote:

Please inform me when the 64 bit " IAccessible2Proxy.dll " is
ready, because my project is pending due to this issue.
If you need it sooner than someone is able to provide it, you can build 
one yourself using the instructions already linked:

http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/comproxydll

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] Accessibility-ia2 Digest, Vol 72, Issue 1

[James Teh]

On 5/11/2014 4:14 PM, Rajesh V R wrote:

Today I just installed NVDA on 64 bit OS, and then tested my application
with 64 bit browser. Then the result was positive.
That's because NVDA injects into processes. Among other things, it 
registers the IA2 proxy. We don't register it system wide.



the IAccessible2Proxy.DLL from the path "C:\Program Files
(x86)\NVDA\lib64".  ...
try to
register the dll using "regsvr32" command from SysWow64 folder. Then it
shows one error message " *The module IAccessible2Proxy.dll was loaded
but the entry-point DllRegisterServer was not found* ".
Ah. It looks like you can't register the NVDA proxy dlls. We don't need 
that functionality, so we don't build it. Unfortunately, that means 
you'll need to build your own dll. This should be easy enough once you 
have the IA2 idl, though I don't remember the exact instructions.


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] IAccessible2 Proxy.DLL for 64 bit browser support

[James Teh]

As far as I know, there is no official 64 bit proxy dll. However, you 
are correct that one is needed to use IA2 out-of-process where a 64 bit 
process is involved.


We build our own 64 bit proxy for NVDA, so you could download NVDA and 
get it from there. Note that this is integrated into our build system, 
so it isn't available separately. I'm not sure if this would cause any 
licensing/legal issues for you.


Jamie

On 3/11/2014 5:46 PM, Rajesh V R wrote:

Hello,

I'm working with some browser depending projects, and using VC++. So how
can I use the " IAccessible2 Proxy.DLL" for 64 bit browsers? Is there
any other 64bit version available?
Because, everytime I'm getting the error code "80040154" [HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)].
I'm registering the "IAccessible2Proxy.DLL" from Syswow64 folder using
the command "regsvr32".
The problem is mainly with Google Chrome 64bit. Please help me to solve
this issue.

Thanks,
Rajesh


___
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] STATE_INDETERMINATE as a means to indicate things like unknowable set size?

[James Teh]

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.


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

Re: [Accessibility-ia2] IA2_ROLE_TOGGLE_BUTTON is not recommend by spec

[James Teh]

Hi Rich,

This is certainly how Firefox exposes it, except that Firefox also 
exposes the checkable state, which is a related (but separate) issue. 
This option certainly makes sense.


The alternative is to use a role of button and introduce a pressable 
state or document that the checkable state on buttons actually means 
pressable.


I don't mind which from a principle standpoint, but it would seem the 
former will have less impact, given that Firefox is already doing it.


Jamie

On 26/02/2014 9:29 AM, Richard Schwerdtfeger wrote:

Jamie,

In ARIA you apply aria-pressed="true" or aria-pressed="false" it will
become a toggle button. From the implementation guide should we say
something about the pressed state.

IAccessible2: If _aria-pressed_
<http://www.w3.org/TR/2014/PR-wai-aria-20140206/states_and_properties#aria-pressed>
 is
not *undefined*, it *SHOULD* be exposed as IA2_ROLE_TOGGLE_BUTTON

IOW if you are ever to use a pressed state then you should change the
role to IA2_ROLE_TOGGLE_BUTTON

Cheers,
Rich

Rich Schwerdtfeger

Inactive hide details for James Teh ---02/20/2014 05:50:12 PM---Further
to this, the IA2 spec recommends using ROLE_SYSTEM_PUSHJames Teh
---02/20/2014 05:50:12 PM---Further to this, the IA2 spec recommends
using ROLE_SYSTEM_PUSHBUTTON.  The problem with this is tha

From: James Teh 
To: accessibility-ia2@lists.linuxfoundation.org
Date: 02/20/2014 05:50 PM
Subject: Re: [Accessibility-ia2] IA2_ROLE_TOGGLE_BUTTON is not recommend
by spec
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org





Further to this, the IA2 spec recommends using ROLE_SYSTEM_PUSHBUTTON.
The problem with this is that it's not possible to tell whether the
button can be toggled when it is not pressed. That is, you can't tell
whether it's just a normal button that can't be toggled or whether it's
a button that can be toggled (pressed or not pressed).

Jamie

On 21/02/2014 12:15 AM, Alexander Surkov wrote:
 > Hi. IA2 spec doesn't recommend to use TOGGLE_BUTTON role [1]:
 >
 > Note: IA2_ROLE_TOGGLE_BUTTON should not be used.  Instead,
use MSAA's
 > ROLE_SYSTEM_PUSHBUTTON and STATE_SYSTEM_PRESSED.
 >
 > However it's in use in Firefox for years [2]. Note, ATK's toggle button
 > doesn't have similar wording.
 >
 > Is there any particular reason of this wording?
 >
 > Thank you.
 > Alexander.
 >
 > [1]
 >
http://accessibility.linuxfoundation.org/a11yspecs/ia2/api/AccessibleRole.idl
 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=390284
 > [3] https://developer.gnome.org/atk/unstable/AtkObject.html
 >
 >
 > ___
 > Accessibility-ia2 mailing list
 > Accessibility-ia2@lists.linuxfoundation.org
 > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
 >

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




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

Re: [Accessibility-ia2] IA2_ROLE_TOGGLE_BUTTON is not recommend by spec

[James Teh]

Further to this, the IA2 spec recommends using ROLE_SYSTEM_PUSHBUTTON. 
The problem with this is that it's not possible to tell whether the 
button can be toggled when it is not pressed. That is, you can't tell 
whether it's just a normal button that can't be toggled or whether it's 
a button that can be toggled (pressed or not pressed).


Jamie

On 21/02/2014 12:15 AM, Alexander Surkov wrote:

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

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

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

Is there any particular reason of this wording?

Thank you.
Alexander.

[1]
http://accessibility.linuxfoundation.org/a11yspecs/ia2/api/AccessibleRole.idl
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=390284
[3] https://developer.gnome.org/atk/unstable/AtkObject.html


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



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

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

[James Teh]

On 16/07/2013 11:09 PM, Pete Brunet wrote:

The site is now updated:
http://accessibility.linuxfoundation.org/a11yspecs/ia2/
Hopefully buildapi.sh and ia2_api_all.idl are OK now.

The idl is now correct. Thanks!

Jamie

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

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

[James Teh]

On 9/07/2013 5:13 PM, James Teh wrote:

Now, the
IDL includes Accessible2.idl before AccessibleRelation.idl, which breaks
because IAccessible2 depends on IAccessibleRelation.
Alex: I'm curious as to why you didn't hit this issue at Mozilla. Does 
Mozilla use the official merged IDL or do you generate your own?


Jamie

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

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

[James Teh]

On 22/04/2013 4:28 PM, James Teh wrote:

There is a major problem with the merged IDL. It does not include the
IAccessibleTable.idl file.


This is now fixed, but unfortunately, there's more bad news. Now, the 
IDL includes Accessible2.idl before AccessibleRelation.idl, which breaks 
because IAccessible2 depends on IAccessibleRelation. It looks like 
buildapi.sh was changed to list all of the .idl files in alphabetical 
order. I suspect there will be other similar problems once 
AccessibleRelation is moved. I think it's best to return to the old 
order and just add the missing AccessibleTable.idl.


I'm attaching a modified version of buildapi.sh which does just this.

Jamie

--
James Teh
Director, NV Access Limited
Ph + 61 7 5667 8372
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @nvaccess
# run build.sh from the IA2 directory

# make sure we have Cygwin
if [ ! -d /cygdrive/c ]; then
echo 'Expected to find Cygwin'
exit 1
fi

# make sure we have the proper directory structure
if [ ! -d api ]; then
echo 'Expected to find ./api'
exit 1
fi

# make sure we have Doxygen
if [ ! -x /cygdrive/c/program\ files/doxygen/bin/doxygen.exe ]; then
echo 'Expected to find c:/program files/doxygen/bin/doxygen.exe'
exit 1
fi

cd api

# make sure we have a Doxygen configuration file
if [ ! -f ../doxygen.conf ]; then
echo 'Expected to find doxygen.conf'
exit 1
fi

# clean up test dir
if [ -f ../IDL-Test/dlldata.c ]; then
rm ../IDL-Test/*.c
rm ../IDL-Test/*.h
fi

cp ../IDL-Test/StdAfxSave/*.* ../IDL-Test

# remove previous autogenerated Doxygen files
if [ -d ../docs ]; then
rm -rf ../docs
fi

# generate IDL documentation with Doxygen
/cygdrive/c/program\ files/doxygen/bin/doxygen ../doxygen.conf

# remove any previous autogenerated merged IDL file
if [ -f ../ia2_api_all.idl ]; then
rm ../ia2_api_all.idl
fi

# generate merged IDL file - IA2TypeLibrary.idl must be at the end
cat IA2CommonTypes.idl AccessibleRelation.idl AccessibleAction.idl 
AccessibleRole.idl AccessibleStates.idl Accessible2.idl Accessible2_2.idl 
AccessibleComponent.idl AccessibleValue.idl AccessibleText.idl 
AccessibleText2.idl AccessibleEditableText.idl AccessibleHyperlink.idl 
AccessibleHyperText.idl AccessibleHypertext2.idl AccessibleTable.idl 
AccessibleTable2.idl AccessibleTableCell.idl AccessibleImage.idl 
AccessibleEventId.idl AccessibleApplication.idl AccessibleDocument.idl 
IA2TypeLibrary.idl | sed -e 's/import "[A-Za-z0-9].*$//g' - | cat 
api_all_headers.idl - > ../ia2_api_all.idl

cd ..

# remove previous autogenerated zip file
if [ -f ia2-api-`date +%Y%m%d`.zip ]; then
rm ia2-api-`date +%Y%m%d`.zip
fi

# package merged IDL file and documentation
zip -9r ia2-api-`date +%Y%m%d`.zip ia2_api_all.idl api/*.idl docs

# list packaged file for visual confirmation
echo ''
ls -l ia2-api-`date +%Y%m%d`.zip
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Object attribute format

[James Teh]

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

attribute:value1,value2 seems acceptable.

Agreed.


Does it implicitly mean that in case of several values the following
format is expected (as no subattributes were used):
"attribute:value1,value2"?
While the format makes sense, I don't think it's implicit. It isn't 
something I considered while writing NVDA's IA2 attributes parser, so it 
won't handle this without changes. It's probably reasonable that others 
may not have considered it either.


Jamie

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

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

[James Teh]

Hi Pete,

On 16/04/2013 7:15 AM, Pete Brunet wrote:

The new version is now on the LF site at
http://accessibility.linuxfoundation.org/a11yspecs/ia2/.
There is a major problem with the merged IDL. It does not include the 
IAccessibleTable.idl file. It seems this was removed from buildapi.sh in 
or before September last year when you released the initial version of 
1.3 for review.


Thanks,
Jamie

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

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

[James Teh]

On 16/04/2013 7:15 AM, Pete Brunet wrote:

The new version is now on the LF site at
http://accessibility.linuxfoundation.org/a11yspecs/ia2/.

This page:

http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2

still says 1.2.1, even though the links point to 1.3.

Jamie

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

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

[James Teh]

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

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

...

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

This text needs to be changed for the new method.

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


Jamie

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

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

[James Teh]

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


Jamie

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

Alex, Brett, Jamie, What do you recommend?

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

Return the text offset in the immediate parent node.

2) Do not add this method.

3) Something else.

Pete

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

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

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

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

Thank you.
Alex.


On Mon, Feb 11, 2013 at 11:00 AM, James Teh  wrote:

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

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

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



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

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



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

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


Jamie

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

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



--
*Pete Brunet*

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


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

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

[James Teh]

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

Hi, Jamie. If text leafs implement IAccessibleHyperlink but previously
IAccessibleHyperlink was implemented by embedded objects only then
this might be something that AT relies on.
I guess this is a possibility, though I'd assume that ATs that don't 
need text leaf nodes wouldn't traverse them. We'd certainly need ot 
check, though.



On the another hand parent
IAccessibleHyperText would return a collection of children instead the
collection of embedded objects and AT could have dependencies on it as
well.
Ah. I was imagining that the parent IAccessibleHypertext wouldn't return 
the text leaf nodes. See notes on hack below.



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

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

Jamie

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

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

[James Teh]

On 7/02/2013 1:10 PM, Pete Brunet wrote:

Alex, Do you see any need to restrict this to the immediate parent? I'm
going to assume not in the following:
HRESULT IAccessible2_2::offsetInAncestorText (
I'm not sure it makes sense to do this for ancestors other than the 
immediate parent. As I understand it, the point of this method is to get 
back into the realm of IAccessibleText when the text is mirrored in text 
leaf nodes. If there's an accessible between the text leaf and its 
IAccessibleText object, the in-between accessible could itself consume 
offsets in the text. if it is decided to allow it for ancestors, the 
method should probably also return the relevant ancestor.


Alex, can you explain why using IAccessibleHyperlink breaks backwards 
compatibility as opposed to adding this new method?


Jamie

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

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

[James Teh]

Brett, can you comment as to whether (and why) option 4 isn't feasible?

Thanks,
Jamie

On 7/02/2013 3:43 AM, Pete Brunet wrote:

Since there is a need for this and the solution is easy to implement it
seems worth adding.  Here is a draft for review.

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

Return text offset in parent.

Determine the parent accessible which implements IAccessibleText and
return the offset in that object which corresponds to the beginning of
the text associated with this accessible.  If this accessible implements
IAccessibleText, 0 will be returned.

Returns:
   S_OK is returned if this accessible or a parent accessible implements
IAccessibleText.
   S_FALSE is returned if no nodes implementing IAccessibleText are
found; [out] value is 0.

On 2/5/13 10:58 PM, Alexander Surkov wrote:

Hi, Pete.

Options were discussed:
1) make text leaf accessible implement IAccessibleText (I didn't like
it, 
seehttp://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
2) make text leaf accessible implement IAccessibleHyperLink (I didn't
like it, 
seehttp://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001731.html)
3) add a new method DescendantOffset(IAccessible* acc, long* offset)
like Brett suggested (see
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html).
I don't mind. It's easy to implement.
4) do nothing (Jamie mentioned that pure
IAccessibleText/HyperLink/HyperText should work also as alternative
approach to the approach described by Brett, but here we probably run
into restrictions of proprietary softwares).

Thank you.
Alex.


On Wed, Feb 6, 2013 at 2:31 AM, Pete Brunet  wrote:

To all,

Please review the thread Brett started at:
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html

to see if any further progress can be made on this issue.


On 2/5/13 8:46 AM, Brett Lewis wrote:

Hi,
I wish we could get it in but it definitely sounded like there was no
consensus on the issue, so let's let it go.
Thanks,
Brett



From: Pete Brunet [mailto:p...@a11ysoft.com]
Sent: Monday, February 04, 2013 7:02 PM
To: Brett Lewis
Cc: IAccessible2 mailing list
Subject: Re: [Accessibility-ia2] Plea for a new function

Hi Brett, Is this still an issue for you?  We're very near the end of
discussions for IA2 1.3 and wanted to see if more discussion is needed on
this issue.  -Pete

On 11/26/12 7:03 PM, James Teh wrote:

On 27/11/2012 8:02 AM, Brett Lewis wrote:

I am getting the Iaccessible tree.  I then find that I want the text
attributes for one of my leaf nodes and find that I have to go back up the
Iaccessible tree to find the nearest Iaccessible node that allow QI to
IAccessibleText and then trying to figure out how to map the result back
down to my Iaccessible leaf node.

If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e.
pretend they don't exist. That way, you're only dealing with nodes that
support IAccessibleText. However, there may well be a good reason you can't
do this.

Jamie


--
Pete Brunet

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


--
Pete Brunet

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

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



--
*Pete Brunet*

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


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



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

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

[James Teh]

On 27/11/2012 8:02 AM, Brett Lewis wrote:

I am getting the Iaccessible tree.  I then find that I want the text attributes 
for one of my leaf nodes and find that I have to go back up the Iaccessible 
tree to find the nearest Iaccessible node that allow QI to IAccessibleText and 
then trying to figure out how to map the result back down to my Iaccessible 
leaf node.
If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e. 
pretend they don't exist. That way, you're only dealing with nodes that 
support IAccessibleText. However, there may well be a good reason you 
can't do this.


Jamie

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

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

[James Teh]

Hi Brett,

Out of curiosity, how are you getting the text leaf nodes in the first 
place? Ideally, this should all be done using the IAccessibleText 
interface on the parent. I'm keenly aware that there are cases where 
this isn't practical, but I thought I'd ask nevertheless.


Jamie

On 27/11/2012 5:14 AM, Brett Lewis wrote:

Hi,
I don't have a strong preference for a given solution.  If everyone prefers 
implementing IAccessibleHyperLink on the leaf nodes, that is fine.
Alex said it would be hard to implement IAccessibleText on all the text leaf 
nodes so Jamie's IAccessibleHyperLink solution or A pair of new functions to 
retrieve child at offset and offset of descendant seem like the only options.
As I said, the two cases of concern for me are identifying the text attributes 
for a given text leaf node that doesn't support IaccessibleText and to obtain 
the rectangle enclosing specific characters in a text leaf node.
Thanks,
Brett


-Original Message-
From: accessibility-ia2-boun...@lists.linuxfoundation.org 
[mailto:accessibility-ia2-boun...@lists.linuxfoundation.org] On Behalf Of 
Alexander Surkov
Sent: Tuesday, November 20, 2012 8:30 PM
To: James Teh
Cc: IAccessible2 mailing list
Subject: Re: [Accessibility-ia2] Plea for a new function

Hi, Jamie. I think Brett meant accessible object for text node (aka text leaf 
accessible).

In general accessible objects for text nodes aren't really necessary since they 
dupe info that is provided by IAccessibleText on the container. So there's no 
need for them in IA2 world, they are rather MSAA heritage. However I has been 
told that having accessible objects for text nodes is still useful for AT (I'm 
not really aware of
details) and that's why we keep them in Firefox btw. This is a reason why I 
don't want text nodes to implement IAccessibleText (besides it won't be trivial 
to implement).

IAccessibleHyperlink idea might be ok, it's not backward compatible though and 
makes nsIAccessibleHyperText nearly useless since it dupes
IAccessbile/IAccessbile2 methods.

Having a new method that returns an offset for a child (and child by
offset?) might be ok.

Thank you.
Alex.


On Wed, Nov 21, 2012 at 9:11 AM, James Teh  wrote:

Hi.

There are two problems here:
1. It's unclear what is considered the "text" of a descendant node
which doesn't support IAccessibleText. It could be accName, accValue,
accDescription, etc. or some combination thereof.
2. This assumes that a descendant node's "text" actually is contained
in the ancestor IAccessibleText object, which might not be the case.
Of course, I guess the method could just fail if this weren't the case.

Also, why not just implement IAccessibleText on the descendant nodes?

In any case, I don't think a new method is required for this. You can
implement IAccessibleHyperlink on the descendant nodes. The startIndex
and endIndex properties of IAccessibleHyperlink should give you what you need.

Jamie


On 21/11/2012 9:30 AM, Brett Lewis wrote:


All:
I have recently run into a situation for which there presently
doesn't appear to be a good solution.
1.  The problem.  I wished to obtain the attributes for the text at a
particular offset.  This is straightforward using IAccessibleText and
just asking for the attributes at the offset of interest.  The
difficulty is that the node whose text attributes I wanted didn't
support IAccessibleText.  One of its ancestors did and this ancestor
did contain information about the attributes I needed.  The question
then became, how can I find out where in a given IAccessibleText
string does a descendants node text begin.  I haven't found an easy
way to answer this question.
2.  Proposed solution:  Add a new function that returns the offset in
the current IAccessibleText text string for a given IAccessible for a
descendant. So something like:
DescendantOffset(IAccessible* acc,VARIANT varChild, long* offset) I
have no strong preference for exactly how this should be handled,
just the need for such a function.
I know the 1.3 version of the IAccessible2 specification is nearly
ready, but I would like to see if this new function could be included.
In addition to the attributes for text at a given offset, I have also
seen a case where we needed the rectangle for particular characters.
Again, in this instance, we needed to locate the nearest ancestor
supporting IAccessibleText and try to determine the offset in this
ancestor of the node of interest.
What does everyone think about such an addition?
Any feedback would be much appreciated.
Thanks,
Brett Lewis


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



--
James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess

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

[James Teh]

Hi.

There are two problems here:
1. It's unclear what is considered the "text" of a descendant node which 
doesn't support IAccessibleText. It could be accName, accValue, 
accDescription, etc. or some combination thereof.
2. This assumes that a descendant node's "text" actually is contained in 
the ancestor IAccessibleText object, which might not be the case. Of 
course, I guess the method could just fail if this weren't the case.


Also, why not just implement IAccessibleText on the descendant nodes?

In any case, I don't think a new method is required for this. You can 
implement IAccessibleHyperlink on the descendant nodes. The startIndex 
and endIndex properties of IAccessibleHyperlink should give you what you 
need.


Jamie

On 21/11/2012 9:30 AM, Brett Lewis wrote:

All:
I have recently run into a situation for which there presently doesn't
appear to be a good solution.
1.  The problem.  I wished to obtain the attributes for the text at a
particular offset.  This is straightforward using IAccessibleText and
just asking for the attributes at the offset of interest.  The
difficulty is that the node whose text attributes I wanted didn't
support IAccessibleText.  One of its ancestors did and this ancestor did
contain information about the attributes I needed.  The question
then became, how can I find out where in a given IAccessibleText string
does a descendants node text begin.  I haven't found an easy way to
answer this question.
2.  Proposed solution:  Add a new function that returns the offset in
the current IAccessibleText text string for a given IAccessible for a
descendant. So something like:
DescendantOffset(IAccessible* acc,VARIANT varChild, long* offset)
I have no strong preference for exactly how this should be handled, just
the need for such a function.
I know the 1.3 version of the IAccessible2 specification is nearly
ready, but I would like to see if this new function could be included.
In addition to the attributes for text at a given offset, I have also
seen a case where we needed the rectangle for particular characters.
Again, in this instance, we needed to locate the nearest ancestor
supporting IAccessibleText and try to determine the offset in this
ancestor of the node of interest.
What does everyone think about such an addition?
Any feedback would be much appreciated.
Thanks,
Brett Lewis


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



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

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

[James Teh]

On 10/10/2012 5:31 PM, Alexander Surkov wrote:

Using strings [for IAccessibleAction]
is a touch more expensive, but it's negligible and more extensible.

we can go with VARIANT as we did for object attributes.
I'm not sure this makes sense. Do you mean standard constants would be 
numeric and custom ones would be strings?


Jamie

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

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

[James Teh]

On 10/10/2012 5:07 PM, Alexander Surkov wrote:

It seems [introducing actions for editable text operations] doesn't answer why 
we can't turn out the whole
IAccessibleEditableText interface into actions.

I agree and tend to think this is the way forward.


Btw, I would prefer doAction taking a BSTR rather than negative
constant. Otherwise we should standardize all possible actions and we
don't leave a room for the server to introduce non-standard actions.
This requires a new method (and thus a new interface), which was the 
main reason for avoiding it. However, I'm not really against this. Using 
strings is a touch more expensive, but it's negligible and more extensible.



6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
go with array instead EnumVariant? Do AT want to get all items at once
even if the document is big and has many links?

It seems we didn't go with EnumVariant at all but we added maxCount
'in' argument. Should we have it here as well?
We could do that. The question is whether an AT is ever going to want to 
retrieve anything other than one or all hyperlinks. I can only come up 
with use cases for one or all.


Jamie

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

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

[James Teh]

On 24/09/2012 2:52 PM, Alexander Surkov wrote:

5) "Document that copyText, cutText, and pasteText are deprecated."
Can you please refresh me on it? The reason specified is "This
function is available via the application's GUI." but it seems it can
be applied to the whole IAccessibleEditableText interface.
I believe there was some talk a while ago about making these all actions 
which can be triggered using the standard action mechanism. This would 
require a way to perform an action given a constant. It is why the idea 
of using negative action indices came up.



6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
go with array instead EnumVariant? Do AT want to get all items at once
even if the document is big and has many links?
Isn't that the whole point of this method? Otherwise, wouldn't 
IAccessibleHypertext::hyperlink be enough? Maybe I'm missing something...



7) IA2_RELATION_GROUPING_OBJECT_FOR: "This object is a grouping object
for the target object." - it'd be nice to give a hint for
implementers. After a time I don't really remember what is it about :)
I guess a grouping object/container would expose this relation referring 
to all objects it contains. Is this really useful?



9)  Description for IA2_RELATION_POPUP_INITIATOR_FOR doesn't make
things really clear for implementers too.

Yeah; I have no idea what this is for. :)

Btw, the used string is
"popInitiatorFor",

Looks like a typo to me.

Thanks,
Jamie

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