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

2016-09-22 Thread Rich Schwerdtfeger
Ok. Thank you

Sent from my iPhone

> On Sep 22, 2016, at 1:34 PM, James Teh  wrote:
> 
> 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  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 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

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

2016-09-16 Thread Rich Schwerdtfeger
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 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
 

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

2016-09-16 Thread 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

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

2016-09-15 Thread Anne van Kesteren
On Thu, Sep 15, 2016 at 11:43 AM, Steve Faulkner
 wrote:
> Provision of a figure role in Acc APIs is not duplicating anything in HTML.
> It is about providing a cross technology identification of a  [feature] that
> does not currently have a specific definition.

Why is the current implementation not sufficient?


> Currently  is defined (and implemented as such) as a group role
> in Acc APis with an accessible name derived from a child  if
> there is one.

It seems that if you have an equivalent situation in SVG where for
some reason you cannot use , you could always use this, no?


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


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

2016-09-15 Thread Steve Faulkner
>
> I'm pretty sure Mozilla isn't interested in duplicating
>
semantics already implemented for HTML in SVG

Provision of a figure role in Acc APIs is not duplicating anything in HTML.
It is about providing a cross technology identification of a  feataure that
does not currently have a specific definition.

Currently  is defined [1] (and implemented as such) as a group role
in Acc APis with an accessible name derived from a child  if
there is one.

The  'figure' role is exposed in some APIs as an object attribute
"xml-roles:figure" but I don't think that this is actually used by any AT.
I believe at least one AT implementer has indicated the use of object
attributes to identify roles is not a preferred option due to technical
overhead of the method.

There has been discussion about a number of aspects of figure acc
implementation, including whether deriving the acc name from figcaption is
appropriate. Currently (in supporting AT/browser combos) announce the
figcaption content and group role when  recieves virtual focus.
They figcaption content is announced again when it recieves virtual focus.
This is suboptimal, but unless an element with group has an accessible
name, it is generally not announced by AT, so the grouping of the
figcaption with the content it captions is lost.

Years ago when figure/figcaption was still newish i looked into how these
elements could be mapped and came up with some suggestions [2]


[1] https://w3c.github.io/aria/html-aam/html-aam.html#el-figure
[2]
https://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/

FWIW I still think that having ARIA figure role without an accompanying
caption role is not going to be helpful as in order for aural UIs, at
least, to convey useful info the figcaption semantics need to be
identified. (IA2 already has a caption role and last i looked firefox
epxoses it)

--

Regards

SteveF
Current Standards Work @W3C


On 15 September 2016 at 09:35, Anne van Kesteren  wrote:

> On Thu, Sep 15, 2016 at 6:10 AM, Rich Schwerdtfeger
>  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.
>
> I'm not sure who Anna is, but if you meant me, that's the opposite of
> what I said. I'm pretty sure Mozilla isn't interested in duplicating
> semantics already implemented for HTML in SVG, since you can just use
> HTML in SVG.
>
>
> --
> https://annevankesteren.nl/
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


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

2016-09-15 Thread Steve Faulkner
On 15 September 2016 at 16:39, Richard Schwerdtfeger 
wrote:

> I don't see any advantages to adding a new IA2 role. The other platforms
> are not doing it either.


Apologies, I got lost in the discussion, Firefox already exposes it as an
object xml-roles:figure which is essentially a construct to expose ARIA
roles not present in platform APIs, so I don't see what the argument about
whether it be added to ARIA is?

--

Regards

SteveF
Current Standards Work @W3C

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


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

2016-09-15 Thread Marcos Caceres
On September 15, 2016 at 2:10:09 PM, Rich Schwerdtfeger
(richsch...@gmail.com) wrote:
> Alex, both Doug and Anna have expressed to you the opinion of the SVG working 
> group to not
> have those elements in SVG. At this point the discussion on adding or using 
> them is not
> productive.

With all due respect, if Mozilla is supposed to implement this, we
need our queries addressed properly.

Mozilla's position is that developers should be able to use existing
HTML element/attributes in SVG, where they are
semantically/structurally useful. It clearly doesn't make sense to
redefine things that are in HTML in some new SVG version.

I would kindly ask that Alex's requests for clarification are addressed.

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


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

2016-09-15 Thread Richard Schwerdtfeger
I don't see any advantages to adding a new IA2 role. The other platforms are not doing it either.
 
This is the current mapping we have in the core-aam:
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-figure
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: Steve Faulkner To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: Anne van Kesteren , IAccessible2 mailing list , Amelia Bellamy-Royds , "asur...@mozilla.com" , Marcos Caceres , Rich Schwerdtfeger , Alexander Surkov Subject: Re: [Accessibility-ia2] Fwd: figure role backgroundsDate: Thu, Sep 15, 2016 9:29 AM 
 
On 15 September 2016 at 15:20, Richard Schwerdtfeger  wrote:

Applying the ARIA role to and SVG element, such as a , will do the same thing as .
yeah i was looking at SVG and thinking the same thing as figure is a special type of grouping role. 
The question is, what are the advantages to adding a specific role in IA2 rather than relying on xml-roles:figure object attribute?
 
--RegardsSteveFCurrent Standards Work @W3C
 

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


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

2016-09-15 Thread Richard Schwerdtfeger
Currently,  maps to the ARIA role="figure" accessibility mapping per the HTML-AAM. Applying the ARIA role to and SVG element, such as a , will do the same thing as .
 
I was in the process of working with Freedom Scientific and NVDA on their implementations when we got held up over the use of  in SVG. If the browser just map implement the ARIA role mapping for the ARIA role or the HTML element  then when we apply the ARIA role mapping to SVG it will look the same to the screen reader vendor as HTML .
 
We have been working toward creating ARIA role semantics, equivalent to HTML semantics, to enable consistency across host languages. Also we have been asked by people in the Web Components community to do this as well.
 
Rich
 
 
 
Rich Schwerdtfeger
 
 
- Original message -From: Anne van Kesteren To: Steve Faulkner Cc: Rich Schwerdtfeger , Alexander Surkov , Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list , Alexander Surkov , Marcos Caceres , Amelia Bellamy-Royds Subject: Re: [Accessibility-ia2] Fwd: figure role backgroundsDate: Thu, Sep 15, 2016 6:34 AM 
On Thu, Sep 15, 2016 at 11:43 AM, Steve Faulkner wrote:> Provision of a figure role in Acc APIs is not duplicating anything in HTML.> It is about providing a cross technology identification of a  [feature] that> does not currently have a specific definition.Why is the current implementation not sufficient?> Currently  is defined (and implemented as such) as a group role> in Acc APis with an accessible name derived from a child  if> there is one.It seems that if you have an equivalent situation in SVG where forsome reason you cannot use , you could always use this, no?--https://annevankesteren.nl/ 
 

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


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

2016-09-14 Thread Rich Schwerdtfeger
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.

We need to continue with the figure role mappings for IA2.

Rich 

Sent from my iPhone

> On Sep 14, 2016, at 4:36 PM, Alexander Surkov <surkov.alexan...@gmail.com> 
> wrote:
> 
> Hi, Rich.
> 
> 
>> On Wed, Sep 14, 2016 at 4:56 PM, Richard Schwerdtfeger <sch...@us.ibm.com> 
>> wrote:
>> Alex,
>>  
>> 1. Figure is not just semantic as you expect  to go with it and 
>> there is no desire for that in SVG
> 
> I wish to have more details on this, because as I see it  is just 
> a label for  and the authors may or may not use it if they want.
> 
>  
>>  
>> 2. If you look at the SVG2 spec. they list all the elements they want in it 
>> (including . They have chosen to NOT have it in the specification 
>> and it is in lock down. 
> 
> I didn't suggested to extend SVG, right?
> 
> Among other things SVG2 says: "SVG 2 Requirement. Resolution: Allow audio, 
> canvas, iframe and video elements from HTML5, don't introduce almost the same 
> but slightly different SVG NS elements. Purpose: To allow various HTML 
> embedded content elements to be used directly in SVG and support dynamic 
> loading of content." [1]. It looks like HTML figure can be re-used in SVG, 
> according to this requirement.
>  
>>  
>> 3. If you recall from the first ARIA 1.1 meeting we had in Toronto (at 
>> Mozilla) the intent was to reproduce HTML semantics in ARIA as they are 
>> needed. This is in large part to ensure that HTML elements can be defined in 
>> terms of ARIA semantics so that they can be mapped to those semantics.
> 
> I'm good to extend ARIA as long as it's needed, but still I need to 
> understand a use case for each new feature.
>  
>>  
>> 4. Given that HTML has a LOT of elements, we are picking those that can be 
>> easily mapped and for which there is an inherent need first. The Web 
>> Platform people want semantics for all HTML elements in ARIA as they want to 
>> get away from using HTML and create their own DOM. So I expect roles for 
>> virtually all HTML elements (including block quotes).
> 
> Are there any links on public discussions where I can learn more about the 
> web platform initiatives and why they need semantics for all HTML elements in 
> ARIA, or could you cc someone, who will kindly outline their ideas on this 
> list, please?
>  
>>  
>> Steve Faulkner asked for a Figure role and we needed one for SVG (Amelia's 
>> email). So, we created a role for it.
> 
> Steve, could you please put your thinking here about figure role?
>  
>>  
>> There are a lot of features in ARIA 1.1 that people need to have us get out 
>> into browsers and we had a limited timeline for ARIA 1.1. It is for these 
>> reasons that we cut the features off putting all HTML roles into ARIA 1.1.
>>  
>> If you would like to participate in setting the bar lower or higher you 
>> should participate more when we start ARIA 2.0. I believe you were at that 
>> first meeting at Mozilla when we kicked off ARIA 1.1 work.
> 
> fair enough, but still I've got more involved at implementation stage, 
> because I'd need to understand each feature I add into Gecko.
> 
> [1] https://www.w3.org/TR/SVG2/embedded.html
> 
>  
>>  
>> Rich
>>  
>> 
>> 
>> Rich Schwerdtfeger
>>  
>>  
>> - Original message -
>> From: Alexander Surkov <surkov.alexan...@gmail.com>
>> Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
>> To: Rich Schwerdtfeger <richsch...@gmail.com>
>> Cc: IA2 List <accessibility-...@lists.linux-foundation.org>, Alexander 
>> Surkov <asur...@mozilla.com>
>> Subject: Re: [Accessibility-ia2] Fwd: figure role backgrounds
>> Date: Wed, Sep 14, 2016 3:17 PM
>>  
>> Hi, Rich. There are still concerns left. Here's my email [1].
>> Alex.
>>  
>> [1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0051.html
>>  
>> On Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger <richsch...@gmail.com> 
>> wrote:
>> Alex, 
>>  
>> Are you satisfied with Amelia’s more detailed response and why it is needed 
>> in SVG? Figures are used a lot in SVG drawings. 
>>  
>> If so, I would like your approval on the figure mapping. I am trying hard to 
>> get ARIA 1.1 wrapped up so that we can focus efforts on helping you and 
>> others on the JavaScript Accessibility API work and other work around ARI

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

2016-09-14 Thread Alexander Surkov
Hi, Rich.


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

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

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



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

I didn't suggested to extend SVG, right?

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


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

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


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

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


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

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


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

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

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



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

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

2016-09-14 Thread Alexander Surkov
Hi, Rich. There are still concerns left. Here's my email [1].
Alex.

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


On Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger 
wrote:

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