WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Announcing Region Labels on OSX

for

Number of posts in this thread: 19 (In chronological order)

From: Jesse Hausler
Date: Thu, May 15 2014 1:56PM
Subject: Announcing Region Labels on OSX
No previous message | Next message →

I'm having trouble using ARIA to get VoiceOver on OSX to announce a
descriptive title for a region.

We're prototyping a builder type application. Think Visio, but way simpler
/ smaller feature set.

We're planning to use the role="application" for the entire thing so we can
control keyboard behavior throughout the product.

The idea we are going with is to have 4 panels the user can switch between:

- Toolbar (at the top)
- Control Panel (on the left)
- Properties Panel (on the right)
- the main working canvas (in the middle)

F6 and Shift+F6 move the user from panel to panel. Each panel has a <span>
with an offscreen class, which labels the panel. We put an aria-labelledby
attribute on the outermost element of the panel which links the descriptive
span.

For example:

<section aria-labelledy="tbar">
<span class="assistiveText" id="tbar">Toolbar</span>
... rest of the panel content...
</section>

I get proper feedback using Jaws and FF: "Toolbar region..."
VoiceOver with both Safari and Chrome will state that his is a Group, which
makes sense, but it wont announce the "Toolbar" part.

We've tried using aria-describedby, aria-label, and a regular old title
attribute. The only thing that works is aria-labelledby with Jaws, nothing
on Mac.

Any experience with this sort of problem? Possible solutions?

Or did i just start myself a blog post? :)

Happy Global Accessibility Awareness Day everyone!

Jesse

From: Paul J. Adam
Date: Thu, May 15 2014 2:16PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

I don't recommend using visually hidden text, you'll find this causes problems later down the road.

For VO OS X you need to add a role=region and use an aria-label instead of visually hidden text.

Role=application is a BIG responsibility! You have to control every keyboard key they press with JavaScript events.

Is the user not going to need any heading quick navigation keys or other screen reader nav keys while using the application?


Paul J. Adam
Accessibility Evangelist
www.deque.com

On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:

> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> descriptive title for a region.
>
> We're prototyping a builder type application. Think Visio, but way simpler
> / smaller feature set.
>
> We're planning to use the role="application" for the entire thing so we can
> control keyboard behavior throughout the product.
>
> The idea we are going with is to have 4 panels the user can switch between:
>
> - Toolbar (at the top)
> - Control Panel (on the left)
> - Properties Panel (on the right)
> - the main working canvas (in the middle)
>
> F6 and Shift+F6 move the user from panel to panel. Each panel has a <span>
> with an offscreen class, which labels the panel. We put an aria-labelledby
> attribute on the outermost element of the panel which links the descriptive
> span.
>
> For example:
>
> <section aria-labelledy="tbar">
> <span class="assistiveText" id="tbar">Toolbar</span>
> ... rest of the panel content...
> </section>
>
> I get proper feedback using Jaws and FF: "Toolbar region..."
> VoiceOver with both Safari and Chrome will state that his is a Group, which
> makes sense, but it wont announce the "Toolbar" part.
>
> We've tried using aria-describedby, aria-label, and a regular old title
> attribute. The only thing that works is aria-labelledby with Jaws, nothing
> on Mac.
>
> Any experience with this sort of problem? Possible solutions?
>
> Or did i just start myself a blog post? :)
>
> Happy Global Accessibility Awareness Day everyone!
>
> Jesse
> > >

From: Jesse Hausler
Date: Thu, May 15 2014 2:36PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Thanks for the quick response Paul.

So you're saying that adding role="region" with aria-label will make this
compatible with more screen readers? Since we already tried aria-label,
what does the role="region" add that would cause aria-label to begin
working?

As an aside, would role="group" be more appropriate?

Yes, we definitely understand the responsibility of the application role
and intend to use JS throughout to control keyboard focus.

At this point, we're still prototyping to see if this is the best way
forward.

Tell me more about your concerns with visually hidden text. It's a method
we use extensively in our products.

Jesse

On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> I don't recommend using visually hidden text, you'll find this causes
> problems later down the road.
>
> For VO OS X you need to add a role=region and use an aria-label instead of
> visually hidden text.
>
> Role=application is a BIG responsibility! You have to control every
> keyboard key they press with JavaScript events.
>
> Is the user not going to need any heading quick navigation keys or other
> screen reader nav keys while using the application?
>
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> > descriptive title for a region.
> >
> > We're prototyping a builder type application. Think Visio, but way
> simpler
> > / smaller feature set.
> >
> > We're planning to use the role="application" for the entire thing so we
> can
> > control keyboard behavior throughout the product.
> >
> > The idea we are going with is to have 4 panels the user can switch
> between:
> >
> > - Toolbar (at the top)
> > - Control Panel (on the left)
> > - Properties Panel (on the right)
> > - the main working canvas (in the middle)
> >
> > F6 and Shift+F6 move the user from panel to panel. Each panel has a
> <span>
> > with an offscreen class, which labels the panel. We put an
> aria-labelledby
> > attribute on the outermost element of the panel which links the
> descriptive
> > span.
> >
> > For example:
> >
> > <section aria-labelledy="tbar">
> > <span class="assistiveText" id="tbar">Toolbar</span>
> > ... rest of the panel content...
> > </section>
> >
> > I get proper feedback using Jaws and FF: "Toolbar region..."
> > VoiceOver with both Safari and Chrome will state that his is a Group,
> which
> > makes sense, but it wont announce the "Toolbar" part.
> >
> > We've tried using aria-describedby, aria-label, and a regular old title
> > attribute. The only thing that works is aria-labelledby with Jaws,
> nothing
> > on Mac.
> >
> > Any experience with this sort of problem? Possible solutions?
> >
> > Or did i just start myself a blog post? :)
> >
> > Happy Global Accessibility Awareness Day everyone!
> >
> > Jesse
> > > > > > >
> > > >

From: Paul J. Adam
Date: Thu, May 15 2014 2:44PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

VoiceOver for iOS tries to go focus on elements that are -9999px sometimes and then the focus jumps to a random control since it can't get to the off screen text.

VO OS X reads "Interact with HTML content Hello World region" for the below code:

<section role="region" aria-label="Hello World"><p>Blah</p></section>



On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:

> Thanks for the quick response Paul.
>
> So you're saying that adding role="region" with aria-label will make this
> compatible with more screen readers? Since we already tried aria-label,
> what does the role="region" add that would cause aria-label to begin
> working?
>
> As an aside, would role="group" be more appropriate?
>
> Yes, we definitely understand the responsibility of the application role
> and intend to use JS throughout to control keyboard focus.
>
> At this point, we're still prototyping to see if this is the best way
> forward.
>
> Tell me more about your concerns with visually hidden text. It's a method
> we use extensively in our products.
>
> Jesse
>
> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I don't recommend using visually hidden text, you'll find this causes
>> problems later down the road.
>>
>> For VO OS X you need to add a role=region and use an aria-label instead of
>> visually hidden text.
>>
>> Role=application is a BIG responsibility! You have to control every
>> keyboard key they press with JavaScript events.
>>
>> Is the user not going to need any heading quick navigation keys or other
>> screen reader nav keys while using the application?
>>
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
>>> descriptive title for a region.
>>>
>>> We're prototyping a builder type application. Think Visio, but way
>> simpler
>>> / smaller feature set.
>>>
>>> We're planning to use the role="application" for the entire thing so we
>> can
>>> control keyboard behavior throughout the product.
>>>
>>> The idea we are going with is to have 4 panels the user can switch
>> between:
>>>
>>> - Toolbar (at the top)
>>> - Control Panel (on the left)
>>> - Properties Panel (on the right)
>>> - the main working canvas (in the middle)
>>>
>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
>> <span>
>>> with an offscreen class, which labels the panel. We put an
>> aria-labelledby
>>> attribute on the outermost element of the panel which links the
>> descriptive
>>> span.
>>>
>>> For example:
>>>
>>> <section aria-labelledy="tbar">
>>> <span class="assistiveText" id="tbar">Toolbar</span>
>>> ... rest of the panel content...
>>> </section>
>>>
>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>>> VoiceOver with both Safari and Chrome will state that his is a Group,
>> which
>>> makes sense, but it wont announce the "Toolbar" part.
>>>
>>> We've tried using aria-describedby, aria-label, and a regular old title
>>> attribute. The only thing that works is aria-labelledby with Jaws,
>> nothing
>>> on Mac.
>>>
>>> Any experience with this sort of problem? Possible solutions?
>>>
>>> Or did i just start myself a blog post? :)
>>>
>>> Happy Global Accessibility Awareness Day everyone!
>>>
>>> Jesse
>>> >>> >>> >>
>> >> >> >>
> > >

From: Jesse Hausler
Date: Thu, May 15 2014 2:56PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

I'll give it a shot and let you know how that goes.

FWIW, this is our offscreen text class. It helps in RTL languages.

.assistiveText{

position:absolute;

border:0;

clip:rect(0,0,0,0);

width:1px;

height:1px;

margin:-1px;
padding:0;
overflow:hidden}

Thanks again,
Jesse


On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> VoiceOver for iOS tries to go focus on elements that are -9999px sometimes
> and then the focus jumps to a random control since it can't get to the off
> screen text.
>
> VO OS X reads "Interact with HTML content Hello World region" for the
> below code:
>
> <section role="region" aria-label="Hello World"><p>Blah</p></section>
>
>
>
> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Thanks for the quick response Paul.
> >
> > So you're saying that adding role="region" with aria-label will make this
> > compatible with more screen readers? Since we already tried aria-label,
> > what does the role="region" add that would cause aria-label to begin
> > working?
> >
> > As an aside, would role="group" be more appropriate?
> >
> > Yes, we definitely understand the responsibility of the application role
> > and intend to use JS throughout to control keyboard focus.
> >
> > At this point, we're still prototyping to see if this is the best way
> > forward.
> >
> > Tell me more about your concerns with visually hidden text. It's a method
> > we use extensively in our products.
> >
> > Jesse
> >
> > On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> I don't recommend using visually hidden text, you'll find this causes
> >> problems later down the road.
> >>
> >> For VO OS X you need to add a role=region and use an aria-label instead
> of
> >> visually hidden text.
> >>
> >> Role=application is a BIG responsibility! You have to control every
> >> keyboard key they press with JavaScript events.
> >>
> >> Is the user not going to need any heading quick navigation keys or other
> >> screen reader nav keys while using the application?
> >>
> >>
> >> Paul J. Adam
> >> Accessibility Evangelist
> >> www.deque.com
> >>
> >> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> >>> descriptive title for a region.
> >>>
> >>> We're prototyping a builder type application. Think Visio, but way
> >> simpler
> >>> / smaller feature set.
> >>>
> >>> We're planning to use the role="application" for the entire thing so we
> >> can
> >>> control keyboard behavior throughout the product.
> >>>
> >>> The idea we are going with is to have 4 panels the user can switch
> >> between:
> >>>
> >>> - Toolbar (at the top)
> >>> - Control Panel (on the left)
> >>> - Properties Panel (on the right)
> >>> - the main working canvas (in the middle)
> >>>
> >>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
> >> <span>
> >>> with an offscreen class, which labels the panel. We put an
> >> aria-labelledby
> >>> attribute on the outermost element of the panel which links the
> >> descriptive
> >>> span.
> >>>
> >>> For example:
> >>>
> >>> <section aria-labelledy="tbar">
> >>> <span class="assistiveText" id="tbar">Toolbar</span>
> >>> ... rest of the panel content...
> >>> </section>
> >>>
> >>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>> VoiceOver with both Safari and Chrome will state that his is a Group,
> >> which
> >>> makes sense, but it wont announce the "Toolbar" part.
> >>>
> >>> We've tried using aria-describedby, aria-label, and a regular old title
> >>> attribute. The only thing that works is aria-labelledby with Jaws,
> >> nothing
> >>> on Mac.
> >>>
> >>> Any experience with this sort of problem? Possible solutions?
> >>>
> >>> Or did i just start myself a blog post? :)
> >>>
> >>> Happy Global Accessibility Awareness Day everyone!
> >>>
> >>> Jesse
> >>> > >>> > >>> > >>
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Jared Smith
Date: Thu, May 15 2014 3:10PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Hidden elements (whether off-screen or clipped) should probably not
contain functional elements such as links or form controls. As Paul
noted, if an item receives focus but is not visible, the browser my
try to scroll to it and sighted users would have no indication as to
what has focus.

Other than that, it's perfectly acceptable way of providing content -
though should certainly be used judiciously. I don't think it would
cause any issues in the case you've presented. Of course if the
necessary text is already on the screen, then it should be used as an
associated label or description rather than duplicating that text in a
hidden element or in an attribute (such as aria-label).

Jared

From: Paul J. Adam
Date: Thu, May 15 2014 4:32PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Ok yeah clip is better for the VO iOS focus issue. I heard clip was deprecated/replaced so I have to explore that eventually.
On May 15, 2014, at 3:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:

> I'll give it a shot and let you know how that goes.
>
> FWIW, this is our offscreen text class. It helps in RTL languages.
>
> .assistiveText{
>
> position:absolute;
>
> border:0;
>
> clip:rect(0,0,0,0);
>
> width:1px;
>
> height:1px;
>
> margin:-1px;
> padding:0;
> overflow:hidden}
>
> Thanks again,
> Jesse
>
>
> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> VoiceOver for iOS tries to go focus on elements that are -9999px sometimes
>> and then the focus jumps to a random control since it can't get to the off
>> screen text.
>>
>> VO OS X reads "Interact with HTML content Hello World region" for the
>> below code:
>>
>> <section role="region" aria-label="Hello World"><p>Blah</p></section>
>>
>>
>>
>> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Thanks for the quick response Paul.
>>>
>>> So you're saying that adding role="region" with aria-label will make this
>>> compatible with more screen readers? Since we already tried aria-label,
>>> what does the role="region" add that would cause aria-label to begin
>>> working?
>>>
>>> As an aside, would role="group" be more appropriate?
>>>
>>> Yes, we definitely understand the responsibility of the application role
>>> and intend to use JS throughout to control keyboard focus.
>>>
>>> At this point, we're still prototyping to see if this is the best way
>>> forward.
>>>
>>> Tell me more about your concerns with visually hidden text. It's a method
>>> we use extensively in our products.
>>>
>>> Jesse
>>>
>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>>
>>>> I don't recommend using visually hidden text, you'll find this causes
>>>> problems later down the road.
>>>>
>>>> For VO OS X you need to add a role=region and use an aria-label instead
>> of
>>>> visually hidden text.
>>>>
>>>> Role=application is a BIG responsibility! You have to control every
>>>> keyboard key they press with JavaScript events.
>>>>
>>>> Is the user not going to need any heading quick navigation keys or other
>>>> screen reader nav keys while using the application?
>>>>
>>>>
>>>> Paul J. Adam
>>>> Accessibility Evangelist
>>>> www.deque.com
>>>>
>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
>>>>> descriptive title for a region.
>>>>>
>>>>> We're prototyping a builder type application. Think Visio, but way
>>>> simpler
>>>>> / smaller feature set.
>>>>>
>>>>> We're planning to use the role="application" for the entire thing so we
>>>> can
>>>>> control keyboard behavior throughout the product.
>>>>>
>>>>> The idea we are going with is to have 4 panels the user can switch
>>>> between:
>>>>>
>>>>> - Toolbar (at the top)
>>>>> - Control Panel (on the left)
>>>>> - Properties Panel (on the right)
>>>>> - the main working canvas (in the middle)
>>>>>
>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
>>>> <span>
>>>>> with an offscreen class, which labels the panel. We put an
>>>> aria-labelledby
>>>>> attribute on the outermost element of the panel which links the
>>>> descriptive
>>>>> span.
>>>>>
>>>>> For example:
>>>>>
>>>>> <section aria-labelledy="tbar">
>>>>> <span class="assistiveText" id="tbar">Toolbar</span>
>>>>> ... rest of the panel content...
>>>>> </section>
>>>>>
>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>>>>> VoiceOver with both Safari and Chrome will state that his is a Group,
>>>> which
>>>>> makes sense, but it wont announce the "Toolbar" part.
>>>>>
>>>>> We've tried using aria-describedby, aria-label, and a regular old title
>>>>> attribute. The only thing that works is aria-labelledby with Jaws,
>>>> nothing
>>>>> on Mac.
>>>>>
>>>>> Any experience with this sort of problem? Possible solutions?
>>>>>
>>>>> Or did i just start myself a blog post? :)
>>>>>
>>>>> Happy Global Accessibility Awareness Day everyone!
>>>>>
>>>>> Jesse
>>>>> >>>>> >>>>> >>>>
>>>> >>>> >>>> >>>>
>>> >>> >>> >>
>> >> >> >>
> > >

From: Jesse Hausler
Date: Thu, May 15 2014 6:09PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Definitely good advice all around.

We don't use that class for anything functional or actionable. Just for
text that isn't displayed visually, but probably should be... form labels,
"missing" headings, panel descriptions etc. Although we do use it to
compliment icon-fonts inside of anchors or buttons. But the anchor itself
is onscreen.

I hadn't heard about clip being used specifically for VO iOS focus issues.
it does work on VO-iOS for reading text only. Still can't find a way to
create a hidden anchor that isn't specifically visible on screen.


On Thu, May 15, 2014 at 3:32 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> Ok yeah clip is better for the VO iOS focus issue. I heard clip was
> deprecated/replaced so I have to explore that eventually.
> On May 15, 2014, at 3:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > I'll give it a shot and let you know how that goes.
> >
> > FWIW, this is our offscreen text class. It helps in RTL languages.
> >
> > .assistiveText{
> >
> > position:absolute;
> >
> > border:0;
> >
> > clip:rect(0,0,0,0);
> >
> > width:1px;
> >
> > height:1px;
> >
> > margin:-1px;
> > padding:0;
> > overflow:hidden}
> >
> > Thanks again,
> > Jesse
> >
> >
> > On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> VoiceOver for iOS tries to go focus on elements that are -9999px
> sometimes
> >> and then the focus jumps to a random control since it can't get to the
> off
> >> screen text.
> >>
> >> VO OS X reads "Interact with HTML content Hello World region" for the
> >> below code:
> >>
> >> <section role="region" aria-label="Hello World"><p>Blah</p></section>
> >>
> >>
> >>
> >> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> Thanks for the quick response Paul.
> >>>
> >>> So you're saying that adding role="region" with aria-label will make
> this
> >>> compatible with more screen readers? Since we already tried aria-label,
> >>> what does the role="region" add that would cause aria-label to begin
> >>> working?
> >>>
> >>> As an aside, would role="group" be more appropriate?
> >>>
> >>> Yes, we definitely understand the responsibility of the application
> role
> >>> and intend to use JS throughout to control keyboard focus.
> >>>
> >>> At this point, we're still prototyping to see if this is the best way
> >>> forward.
> >>>
> >>> Tell me more about your concerns with visually hidden text. It's a
> method
> >>> we use extensively in our products.
> >>>
> >>> Jesse
> >>>
> >>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>>
> >>>> I don't recommend using visually hidden text, you'll find this causes
> >>>> problems later down the road.
> >>>>
> >>>> For VO OS X you need to add a role=region and use an aria-label
> instead
> >> of
> >>>> visually hidden text.
> >>>>
> >>>> Role=application is a BIG responsibility! You have to control every
> >>>> keyboard key they press with JavaScript events.
> >>>>
> >>>> Is the user not going to need any heading quick navigation keys or
> other
> >>>> screen reader nav keys while using the application?
> >>>>
> >>>>
> >>>> Paul J. Adam
> >>>> Accessibility Evangelist
> >>>> www.deque.com
> >>>>
> >>>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >>>> wrote:
> >>>>
> >>>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> >>>>> descriptive title for a region.
> >>>>>
> >>>>> We're prototyping a builder type application. Think Visio, but way
> >>>> simpler
> >>>>> / smaller feature set.
> >>>>>
> >>>>> We're planning to use the role="application" for the entire thing so
> we
> >>>> can
> >>>>> control keyboard behavior throughout the product.
> >>>>>
> >>>>> The idea we are going with is to have 4 panels the user can switch
> >>>> between:
> >>>>>
> >>>>> - Toolbar (at the top)
> >>>>> - Control Panel (on the left)
> >>>>> - Properties Panel (on the right)
> >>>>> - the main working canvas (in the middle)
> >>>>>
> >>>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
> >>>> <span>
> >>>>> with an offscreen class, which labels the panel. We put an
> >>>> aria-labelledby
> >>>>> attribute on the outermost element of the panel which links the
> >>>> descriptive
> >>>>> span.
> >>>>>
> >>>>> For example:
> >>>>>
> >>>>> <section aria-labelledy="tbar">
> >>>>> <span class="assistiveText" id="tbar">Toolbar</span>
> >>>>> ... rest of the panel content...
> >>>>> </section>
> >>>>>
> >>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>>>> VoiceOver with both Safari and Chrome will state that his is a Group,
> >>>> which
> >>>>> makes sense, but it wont announce the "Toolbar" part.
> >>>>>
> >>>>> We've tried using aria-describedby, aria-label, and a regular old
> title
> >>>>> attribute. The only thing that works is aria-labelledby with Jaws,
> >>>> nothing
> >>>>> on Mac.
> >>>>>
> >>>>> Any experience with this sort of problem? Possible solutions?
> >>>>>
> >>>>> Or did i just start myself a blog post? :)
> >>>>>
> >>>>> Happy Global Accessibility Awareness Day everyone!
> >>>>>
> >>>>> Jesse
> >>>>> > >>>>> > >>>>> > >>>>
> >>>> > >>>> > >>>> > >>>>
> >>> > >>> > >>> > >>
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Jesse Hausler
Date: Thu, May 15 2014 6:38PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Paul,

I tried adding role="region" aria-label="hello world" to our <section>. It
actually didn't work for us on OSX in Chrome or Safari.

I wonder if it has something to do with how one enters the region.

Jesse


On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> VoiceOver for iOS tries to go focus on elements that are -9999px sometimes
> and then the focus jumps to a random control since it can't get to the off
> screen text.
>
> VO OS X reads "Interact with HTML content Hello World region" for the
> below code:
>
> <section role="region" aria-label="Hello World"><p>Blah</p></section>
>
>
>
> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Thanks for the quick response Paul.
> >
> > So you're saying that adding role="region" with aria-label will make this
> > compatible with more screen readers? Since we already tried aria-label,
> > what does the role="region" add that would cause aria-label to begin
> > working?
> >
> > As an aside, would role="group" be more appropriate?
> >
> > Yes, we definitely understand the responsibility of the application role
> > and intend to use JS throughout to control keyboard focus.
> >
> > At this point, we're still prototyping to see if this is the best way
> > forward.
> >
> > Tell me more about your concerns with visually hidden text. It's a method
> > we use extensively in our products.
> >
> > Jesse
> >
> > On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> I don't recommend using visually hidden text, you'll find this causes
> >> problems later down the road.
> >>
> >> For VO OS X you need to add a role=region and use an aria-label instead
> of
> >> visually hidden text.
> >>
> >> Role=application is a BIG responsibility! You have to control every
> >> keyboard key they press with JavaScript events.
> >>
> >> Is the user not going to need any heading quick navigation keys or other
> >> screen reader nav keys while using the application?
> >>
> >>
> >> Paul J. Adam
> >> Accessibility Evangelist
> >> www.deque.com
> >>
> >> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> >>> descriptive title for a region.
> >>>
> >>> We're prototyping a builder type application. Think Visio, but way
> >> simpler
> >>> / smaller feature set.
> >>>
> >>> We're planning to use the role="application" for the entire thing so we
> >> can
> >>> control keyboard behavior throughout the product.
> >>>
> >>> The idea we are going with is to have 4 panels the user can switch
> >> between:
> >>>
> >>> - Toolbar (at the top)
> >>> - Control Panel (on the left)
> >>> - Properties Panel (on the right)
> >>> - the main working canvas (in the middle)
> >>>
> >>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
> >> <span>
> >>> with an offscreen class, which labels the panel. We put an
> >> aria-labelledby
> >>> attribute on the outermost element of the panel which links the
> >> descriptive
> >>> span.
> >>>
> >>> For example:
> >>>
> >>> <section aria-labelledy="tbar">
> >>> <span class="assistiveText" id="tbar">Toolbar</span>
> >>> ... rest of the panel content...
> >>> </section>
> >>>
> >>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>> VoiceOver with both Safari and Chrome will state that his is a Group,
> >> which
> >>> makes sense, but it wont announce the "Toolbar" part.
> >>>
> >>> We've tried using aria-describedby, aria-label, and a regular old title
> >>> attribute. The only thing that works is aria-labelledby with Jaws,
> >> nothing
> >>> on Mac.
> >>>
> >>> Any experience with this sort of problem? Possible solutions?
> >>>
> >>> Or did i just start myself a blog post? :)
> >>>
> >>> Happy Global Accessibility Awareness Day everyone!
> >>>
> >>> Jesse
> >>> > >>> > >>> > >>
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Paul J. Adam
Date: Thu, May 15 2014 6:51PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

have to use linear navigation to get to the container
On May 15, 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:

> Paul,
>
> I tried adding role="region" aria-label="hello world" to our <section>. It
> actually didn't work for us on OSX in Chrome or Safari.
>
> I wonder if it has something to do with how one enters the region.
>
> Jesse
>
>
> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> VoiceOver for iOS tries to go focus on elements that are -9999px sometimes
>> and then the focus jumps to a random control since it can't get to the off
>> screen text.
>>
>> VO OS X reads "Interact with HTML content Hello World region" for the
>> below code:
>>
>> <section role="region" aria-label="Hello World"><p>Blah</p></section>
>>
>>
>>
>> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Thanks for the quick response Paul.
>>>
>>> So you're saying that adding role="region" with aria-label will make this
>>> compatible with more screen readers? Since we already tried aria-label,
>>> what does the role="region" add that would cause aria-label to begin
>>> working?
>>>
>>> As an aside, would role="group" be more appropriate?
>>>
>>> Yes, we definitely understand the responsibility of the application role
>>> and intend to use JS throughout to control keyboard focus.
>>>
>>> At this point, we're still prototyping to see if this is the best way
>>> forward.
>>>
>>> Tell me more about your concerns with visually hidden text. It's a method
>>> we use extensively in our products.
>>>
>>> Jesse
>>>
>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>>
>>>> I don't recommend using visually hidden text, you'll find this causes
>>>> problems later down the road.
>>>>
>>>> For VO OS X you need to add a role=region and use an aria-label instead
>> of
>>>> visually hidden text.
>>>>
>>>> Role=application is a BIG responsibility! You have to control every
>>>> keyboard key they press with JavaScript events.
>>>>
>>>> Is the user not going to need any heading quick navigation keys or other
>>>> screen reader nav keys while using the application?
>>>>
>>>>
>>>> Paul J. Adam
>>>> Accessibility Evangelist
>>>> www.deque.com
>>>>
>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
>>>>> descriptive title for a region.
>>>>>
>>>>> We're prototyping a builder type application. Think Visio, but way
>>>> simpler
>>>>> / smaller feature set.
>>>>>
>>>>> We're planning to use the role="application" for the entire thing so we
>>>> can
>>>>> control keyboard behavior throughout the product.
>>>>>
>>>>> The idea we are going with is to have 4 panels the user can switch
>>>> between:
>>>>>
>>>>> - Toolbar (at the top)
>>>>> - Control Panel (on the left)
>>>>> - Properties Panel (on the right)
>>>>> - the main working canvas (in the middle)
>>>>>
>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
>>>> <span>
>>>>> with an offscreen class, which labels the panel. We put an
>>>> aria-labelledby
>>>>> attribute on the outermost element of the panel which links the
>>>> descriptive
>>>>> span.
>>>>>
>>>>> For example:
>>>>>
>>>>> <section aria-labelledy="tbar">
>>>>> <span class="assistiveText" id="tbar">Toolbar</span>
>>>>> ... rest of the panel content...
>>>>> </section>
>>>>>
>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>>>>> VoiceOver with both Safari and Chrome will state that his is a Group,
>>>> which
>>>>> makes sense, but it wont announce the "Toolbar" part.
>>>>>
>>>>> We've tried using aria-describedby, aria-label, and a regular old title
>>>>> attribute. The only thing that works is aria-labelledby with Jaws,
>>>> nothing
>>>>> on Mac.
>>>>>
>>>>> Any experience with this sort of problem? Possible solutions?
>>>>>
>>>>> Or did i just start myself a blog post? :)
>>>>>
>>>>> Happy Global Accessibility Awareness Day everyone!
>>>>>
>>>>> Jesse
>>>>> >>>>> >>>>> >>>>
>>>> >>>> >>>> >>>>
>>> >>> >>> >>
>> >> >> >>
> > >

From: Birkir R. Gunnarsson
Date: Thu, May 15 2014 7:29PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

role="region" is not considered a landmark by Apple. Therefore any
landmark navigation options in Voiceover do not include regions.
VO announces labels of named regions when user enters/leaves the
regions in course of normal linear navigation.

A further thought on your application design, without having seen it of course.
Make sure to wrap any static piece of content inside div with
role="application" in a container element with role="document".
In forms mode it is hard for screen reader users, particularly
Jaws/NVDA to navigate static piece of text.
This is particularly true with older versions of NVDA (versions prior
to 2014.1)where user is unable to switch to browse mode when inside
divs with role="application".
Cheers and good luck.


On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> have to use linear navigation to get to the container
> On May 15, 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Paul,
>>
>> I tried adding role="region" aria-label="hello world" to our <section>.
>> It
>> actually didn't work for us on OSX in Chrome or Safari.
>>
>> I wonder if it has something to do with how one enters the region.
>>
>> Jesse
>>
>>
>> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> VoiceOver for iOS tries to go focus on elements that are -9999px
>>> sometimes
>>> and then the focus jumps to a random control since it can't get to the
>>> off
>>> screen text.
>>>
>>> VO OS X reads "Interact with HTML content Hello World region" for the
>>> below code:
>>>
>>> <section role="region" aria-label="Hello World"><p>Blah</p></section>
>>>
>>>
>>>
>>> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> Thanks for the quick response Paul.
>>>>
>>>> So you're saying that adding role="region" with aria-label will make
>>>> this
>>>> compatible with more screen readers? Since we already tried aria-label,
>>>> what does the role="region" add that would cause aria-label to begin
>>>> working?
>>>>
>>>> As an aside, would role="group" be more appropriate?
>>>>
>>>> Yes, we definitely understand the responsibility of the application
>>>> role
>>>> and intend to use JS throughout to control keyboard focus.
>>>>
>>>> At this point, we're still prototyping to see if this is the best way
>>>> forward.
>>>>
>>>> Tell me more about your concerns with visually hidden text. It's a
>>>> method
>>>> we use extensively in our products.
>>>>
>>>> Jesse
>>>>
>>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>>
>>>>> I don't recommend using visually hidden text, you'll find this causes
>>>>> problems later down the road.
>>>>>
>>>>> For VO OS X you need to add a role=region and use an aria-label
>>>>> instead
>>> of
>>>>> visually hidden text.
>>>>>
>>>>> Role=application is a BIG responsibility! You have to control every
>>>>> keyboard key they press with JavaScript events.
>>>>>
>>>>> Is the user not going to need any heading quick navigation keys or
>>>>> other
>>>>> screen reader nav keys while using the application?
>>>>>
>>>>>
>>>>> Paul J. Adam
>>>>> Accessibility Evangelist
>>>>> www.deque.com
>>>>>
>>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>>>>> wrote:
>>>>>
>>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
>>>>>> descriptive title for a region.
>>>>>>
>>>>>> We're prototyping a builder type application. Think Visio, but way
>>>>> simpler
>>>>>> / smaller feature set.
>>>>>>
>>>>>> We're planning to use the role="application" for the entire thing so
>>>>>> we
>>>>> can
>>>>>> control keyboard behavior throughout the product.
>>>>>>
>>>>>> The idea we are going with is to have 4 panels the user can switch
>>>>> between:
>>>>>>
>>>>>> - Toolbar (at the top)
>>>>>> - Control Panel (on the left)
>>>>>> - Properties Panel (on the right)
>>>>>> - the main working canvas (in the middle)
>>>>>>
>>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
>>>>> <span>
>>>>>> with an offscreen class, which labels the panel. We put an
>>>>> aria-labelledby
>>>>>> attribute on the outermost element of the panel which links the
>>>>> descriptive
>>>>>> span.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> <section aria-labelledy="tbar">
>>>>>> <span class="assistiveText" id="tbar">Toolbar</span>
>>>>>> ... rest of the panel content...
>>>>>> </section>
>>>>>>
>>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>>>>>> VoiceOver with both Safari and Chrome will state that his is a Group,
>>>>> which
>>>>>> makes sense, but it wont announce the "Toolbar" part.
>>>>>>
>>>>>> We've tried using aria-describedby, aria-label, and a regular old
>>>>>> title
>>>>>> attribute. The only thing that works is aria-labelledby with Jaws,
>>>>> nothing
>>>>>> on Mac.
>>>>>>
>>>>>> Any experience with this sort of problem? Possible solutions?
>>>>>>
>>>>>> Or did i just start myself a blog post? :)
>>>>>>
>>>>>> Happy Global Accessibility Awareness Day everyone!
>>>>>>
>>>>>> Jesse
>>>>>> >>>>>> >>>>>> >>>>>
>>>>> >>>>> >>>>> >>>>>
>>>> >>>> >>>> >>>
>>> >>> >>> >>>
>> >> >> >
> > > >


--
Work hard. Have fun. Make history.

From: Jesse Hausler
Date: Thu, May 15 2014 11:49PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Bikir,

This is an interesting point you make. Part of the reason for wrapping the
entire product in role="application" is so we can follow a model similar to
a microsoft or adobe style building tool.

So you're suggesting that if one of our "panels" has a form inside. I
should wrap the form in a div with role="document". That's fair enough, but
would that limit our ability to have the F6 key control cycling through our
panels?

I'm going to test this out tomorrow. Thanks for the great insight!

Btw, do you know what apple considers a proper landmark? Is there a
resource you can share?

Thanks,
Jesse


On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> role="region" is not considered a landmark by Apple. Therefore any
> landmark navigation options in Voiceover do not include regions.
> VO announces labels of named regions when user enters/leaves the
> regions in course of normal linear navigation.
>
> A further thought on your application design, without having seen it of
> course.
> Make sure to wrap any static piece of content inside div with
> role="application" in a container element with role="document".
> In forms mode it is hard for screen reader users, particularly
> Jaws/NVDA to navigate static piece of text.
> This is particularly true with older versions of NVDA (versions prior
> to 2014.1)where user is unable to switch to browse mode when inside
> divs with role="application".
> Cheers and good luck.
>
>
> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> > have to use linear navigation to get to the container
> > On May 15, 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> Paul,
> >>
> >> I tried adding role="region" aria-label="hello world" to our <section>.
> >> It
> >> actually didn't work for us on OSX in Chrome or Safari.
> >>
> >> I wonder if it has something to do with how one enters the region.
> >>
> >> Jesse
> >>
> >>
> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
> >>> sometimes
> >>> and then the focus jumps to a random control since it can't get to the
> >>> off
> >>> screen text.
> >>>
> >>> VO OS X reads "Interact with HTML content Hello World region" for the
> >>> below code:
> >>>
> >>> <section role="region" aria-label="Hello World"><p>Blah</p></section>
> >>>
> >>>
> >>>
> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>>
> >>>> Thanks for the quick response Paul.
> >>>>
> >>>> So you're saying that adding role="region" with aria-label will make
> >>>> this
> >>>> compatible with more screen readers? Since we already tried
> aria-label,
> >>>> what does the role="region" add that would cause aria-label to begin
> >>>> working?
> >>>>
> >>>> As an aside, would role="group" be more appropriate?
> >>>>
> >>>> Yes, we definitely understand the responsibility of the application
> >>>> role
> >>>> and intend to use JS throughout to control keyboard focus.
> >>>>
> >>>> At this point, we're still prototyping to see if this is the best way
> >>>> forward.
> >>>>
> >>>> Tell me more about your concerns with visually hidden text. It's a
> >>>> method
> >>>> we use extensively in our products.
> >>>>
> >>>> Jesse
> >>>>
> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>>>
> >>>>> I don't recommend using visually hidden text, you'll find this causes
> >>>>> problems later down the road.
> >>>>>
> >>>>> For VO OS X you need to add a role=region and use an aria-label
> >>>>> instead
> >>> of
> >>>>> visually hidden text.
> >>>>>
> >>>>> Role=application is a BIG responsibility! You have to control every
> >>>>> keyboard key they press with JavaScript events.
> >>>>>
> >>>>> Is the user not going to need any heading quick navigation keys or
> >>>>> other
> >>>>> screen reader nav keys while using the application?
> >>>>>
> >>>>>
> >>>>> Paul J. Adam
> >>>>> Accessibility Evangelist
> >>>>> www.deque.com
> >>>>>
> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >>>>> wrote:
> >>>>>
> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to announce a
> >>>>>> descriptive title for a region.
> >>>>>>
> >>>>>> We're prototyping a builder type application. Think Visio, but way
> >>>>> simpler
> >>>>>> / smaller feature set.
> >>>>>>
> >>>>>> We're planning to use the role="application" for the entire thing so
> >>>>>> we
> >>>>> can
> >>>>>> control keyboard behavior throughout the product.
> >>>>>>
> >>>>>> The idea we are going with is to have 4 panels the user can switch
> >>>>> between:
> >>>>>>
> >>>>>> - Toolbar (at the top)
> >>>>>> - Control Panel (on the left)
> >>>>>> - Properties Panel (on the right)
> >>>>>> - the main working canvas (in the middle)
> >>>>>>
> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel has a
> >>>>> <span>
> >>>>>> with an offscreen class, which labels the panel. We put an
> >>>>> aria-labelledby
> >>>>>> attribute on the outermost element of the panel which links the
> >>>>> descriptive
> >>>>>> span.
> >>>>>>
> >>>>>> For example:
> >>>>>>
> >>>>>> <section aria-labelledy="tbar">
> >>>>>> <span class="assistiveText" id="tbar">Toolbar</span>
> >>>>>> ... rest of the panel content...
> >>>>>> </section>
> >>>>>>
> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
> Group,
> >>>>> which
> >>>>>> makes sense, but it wont announce the "Toolbar" part.
> >>>>>>
> >>>>>> We've tried using aria-describedby, aria-label, and a regular old
> >>>>>> title
> >>>>>> attribute. The only thing that works is aria-labelledby with Jaws,
> >>>>> nothing
> >>>>>> on Mac.
> >>>>>>
> >>>>>> Any experience with this sort of problem? Possible solutions?
> >>>>>>
> >>>>>> Or did i just start myself a blog post? :)
> >>>>>>
> >>>>>> Happy Global Accessibility Awareness Day everyone!
> >>>>>>
> >>>>>> Jesse
> >>>>>> > >>>>>> > >>>>>> > >>>>>
> >>>>> > >>>>> > >>>>> > >>>>>
> >>>> > >>>> > >>>> > >>>
> >>> > >>> > >>> > >>>
> >> > >> > >> > >
> > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > >

From: Jonathan Avila
Date: Fri, May 16 2014 6:51AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

[Jessie wrote] Still can't find a way to create a hidden anchor that isn't
specifically visible on screen.

You generally wouldn't want to do this unless the anchor becomes visible
when focused -- if this wasn't the case then you'd have a violation of
Focus Visible SC 2.4.7. Any time you are considering using off-screen
text consider how users with other disabilities such as low vision,
cognitive disabilities, or keyboard-only users might be affected or could
benefit from the screen reader specific technique you are about to apply.

Jonathan

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse Hausler
Sent: Thursday, May 15, 2014 8:10 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Announcing Region Labels on OSX

Definitely good advice all around.

We don't use that class for anything functional or actionable. Just for
text that isn't displayed visually, but probably should be... form labels,
"missing" headings, panel descriptions etc. Although we do use it to
compliment icon-fonts inside of anchors or buttons. But the anchor itself
is onscreen.

I hadn't heard about clip being used specifically for VO iOS focus issues.
it does work on VO-iOS for reading text only. Still can't find a way to
create a hidden anchor that isn't specifically visible on screen.


On Thu, May 15, 2014 at 3:32 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> Ok yeah clip is better for the VO iOS focus issue. I heard clip was
> deprecated/replaced so I have to explore that eventually.
> On May 15, 2014, at 3:56 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > I'll give it a shot and let you know how that goes.
> >
> > FWIW, this is our offscreen text class. It helps in RTL languages.
> >
> > .assistiveText{
> >
> > position:absolute;
> >
> > border:0;
> >
> > clip:rect(0,0,0,0);
> >
> > width:1px;
> >
> > height:1px;
> >
> > margin:-1px;
> > padding:0;
> > overflow:hidden}
> >
> > Thanks again,
> > Jesse
> >
> >
> > On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> VoiceOver for iOS tries to go focus on elements that are -9999px
> sometimes
> >> and then the focus jumps to a random control since it can't get to
> >> the
> off
> >> screen text.
> >>
> >> VO OS X reads "Interact with HTML content Hello World region" for
> >> the below code:
> >>
> >> <section role="region" aria-label="Hello
> >> World"><p>Blah</p></section>
> >>
> >>
> >>
> >> On May 15, 2014, at 3:36 PM, Jesse Hausler
> >> < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> Thanks for the quick response Paul.
> >>>
> >>> So you're saying that adding role="region" with aria-label will
> >>> make
> this
> >>> compatible with more screen readers? Since we already tried
> >>> aria-label, what does the role="region" add that would cause
> >>> aria-label to begin working?
> >>>
> >>> As an aside, would role="group" be more appropriate?
> >>>
> >>> Yes, we definitely understand the responsibility of the
> >>> application
> role
> >>> and intend to use JS throughout to control keyboard focus.
> >>>
> >>> At this point, we're still prototyping to see if this is the best
> >>> way forward.
> >>>
> >>> Tell me more about your concerns with visually hidden text. It's a
> method
> >>> we use extensively in our products.
> >>>
> >>> Jesse
> >>>
> >>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
> >>> < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>>
> >>>> I don't recommend using visually hidden text, you'll find this
> >>>> causes problems later down the road.
> >>>>
> >>>> For VO OS X you need to add a role=region and use an aria-label
> instead
> >> of
> >>>> visually hidden text.
> >>>>
> >>>> Role=application is a BIG responsibility! You have to control
> >>>> every keyboard key they press with JavaScript events.
> >>>>
> >>>> Is the user not going to need any heading quick navigation keys
> >>>> or
> other
> >>>> screen reader nav keys while using the application?
> >>>>
> >>>>
> >>>> Paul J. Adam
> >>>> Accessibility Evangelist
> >>>> www.deque.com
> >>>>
> >>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
> >>>> < = EMAIL ADDRESS REMOVED = >
> >>>> wrote:
> >>>>
> >>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
> >>>>> announce a descriptive title for a region.
> >>>>>
> >>>>> We're prototyping a builder type application. Think Visio, but
> >>>>> way
> >>>> simpler
> >>>>> / smaller feature set.
> >>>>>
> >>>>> We're planning to use the role="application" for the entire
> >>>>> thing so
> we
> >>>> can
> >>>>> control keyboard behavior throughout the product.
> >>>>>
> >>>>> The idea we are going with is to have 4 panels the user can
> >>>>> switch
> >>>> between:
> >>>>>
> >>>>> - Toolbar (at the top)
> >>>>> - Control Panel (on the left)
> >>>>> - Properties Panel (on the right)
> >>>>> - the main working canvas (in the middle)
> >>>>>
> >>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
> >>>>> has a
> >>>> <span>
> >>>>> with an offscreen class, which labels the panel. We put an
> >>>> aria-labelledby
> >>>>> attribute on the outermost element of the panel which links the
> >>>> descriptive
> >>>>> span.
> >>>>>
> >>>>> For example:
> >>>>>
> >>>>> <section aria-labelledy="tbar">
> >>>>> <span class="assistiveText" id="tbar">Toolbar</span> ... rest of
> >>>>> the panel content...
> >>>>> </section>
> >>>>>
> >>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>>>> VoiceOver with both Safari and Chrome will state that his is a
> >>>>> Group,
> >>>> which
> >>>>> makes sense, but it wont announce the "Toolbar" part.
> >>>>>
> >>>>> We've tried using aria-describedby, aria-label, and a regular
> >>>>> old
> title
> >>>>> attribute. The only thing that works is aria-labelledby with
> >>>>> Jaws,
> >>>> nothing
> >>>>> on Mac.
> >>>>>
> >>>>> Any experience with this sort of problem? Possible solutions?
> >>>>>
> >>>>> Or did i just start myself a blog post? :)
> >>>>>
> >>>>> Happy Global Accessibility Awareness Day everyone!
> >>>>>
> >>>>> Jesse
> >>>>> > >>>>> > >>>>> > >>>>
> >>>> > >>>> > >>>> > >>>>
> >>> > >>> > >>> list messages to = EMAIL ADDRESS REMOVED =
> >>
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >>
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
messages to = EMAIL ADDRESS REMOVED =

From: Jonathan Avila
Date: Fri, May 16 2014 6:54AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

[Jesse wrote] Btw, do you know what apple considers a proper landmark? Is
there a resource you can share?

I've noticed inconsistencies with other screen readers too. For example,
NVDA will announce ARIA landmarks and move to them with the d keystroke --
however, HTML5 elements such as nav and aside which have direct ARIA
landmark equivalents are not considered landmarks. This is unfortunate
and causes people to add ARIA roles to native HTML5 code.

Jonathan

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse Hausler
Sent: Friday, May 16, 2014 1:49 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Announcing Region Labels on OSX

Bikir,

This is an interesting point you make. Part of the reason for wrapping the
entire product in role="application" is so we can follow a model similar
to a microsoft or adobe style building tool.

So you're suggesting that if one of our "panels" has a form inside. I
should wrap the form in a div with role="document". That's fair enough,
but would that limit our ability to have the F6 key control cycling
through our panels?

I'm going to test this out tomorrow. Thanks for the great insight!

Btw, do you know what apple considers a proper landmark? Is there a
resource you can share?

Thanks,
Jesse


On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> role="region" is not considered a landmark by Apple. Therefore any
> landmark navigation options in Voiceover do not include regions.
> VO announces labels of named regions when user enters/leaves the
> regions in course of normal linear navigation.
>
> A further thought on your application design, without having seen it
> of course.
> Make sure to wrap any static piece of content inside div with
> role="application" in a container element with role="document".
> In forms mode it is hard for screen reader users, particularly
> Jaws/NVDA to navigate static piece of text.
> This is particularly true with older versions of NVDA (versions prior
> to 2014.1)where user is unable to switch to browse mode when inside
> divs with role="application".
> Cheers and good luck.
>
>
> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> > have to use linear navigation to get to the container On May 15,
> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> Paul,
> >>
> >> I tried adding role="region" aria-label="hello world" to our
<section>.
> >> It
> >> actually didn't work for us on OSX in Chrome or Safari.
> >>
> >> I wonder if it has something to do with how one enters the region.
> >>
> >> Jesse
> >>
> >>
> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
> >>> sometimes and then the focus jumps to a random control since it
> >>> can't get to the off screen text.
> >>>
> >>> VO OS X reads "Interact with HTML content Hello World region" for
> >>> the below code:
> >>>
> >>> <section role="region" aria-label="Hello
> >>> World"><p>Blah</p></section>
> >>>
> >>>
> >>>
> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
> >>> < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>>
> >>>> Thanks for the quick response Paul.
> >>>>
> >>>> So you're saying that adding role="region" with aria-label will
> >>>> make this compatible with more screen readers? Since we already
> >>>> tried
> aria-label,
> >>>> what does the role="region" add that would cause aria-label to
> >>>> begin working?
> >>>>
> >>>> As an aside, would role="group" be more appropriate?
> >>>>
> >>>> Yes, we definitely understand the responsibility of the
> >>>> application role and intend to use JS throughout to control
> >>>> keyboard focus.
> >>>>
> >>>> At this point, we're still prototyping to see if this is the best
> >>>> way forward.
> >>>>
> >>>> Tell me more about your concerns with visually hidden text. It's
> >>>> a method we use extensively in our products.
> >>>>
> >>>> Jesse
> >>>>
> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
> >>>> < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>>>
> >>>>> I don't recommend using visually hidden text, you'll find this
> >>>>> causes problems later down the road.
> >>>>>
> >>>>> For VO OS X you need to add a role=region and use an aria-label
> >>>>> instead
> >>> of
> >>>>> visually hidden text.
> >>>>>
> >>>>> Role=application is a BIG responsibility! You have to control
> >>>>> every keyboard key they press with JavaScript events.
> >>>>>
> >>>>> Is the user not going to need any heading quick navigation keys
> >>>>> or other screen reader nav keys while using the application?
> >>>>>
> >>>>>
> >>>>> Paul J. Adam
> >>>>> Accessibility Evangelist
> >>>>> www.deque.com
> >>>>>
> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
> >>>>> < = EMAIL ADDRESS REMOVED = >
> >>>>> wrote:
> >>>>>
> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
> >>>>>> announce a descriptive title for a region.
> >>>>>>
> >>>>>> We're prototyping a builder type application. Think Visio, but
> >>>>>> way
> >>>>> simpler
> >>>>>> / smaller feature set.
> >>>>>>
> >>>>>> We're planning to use the role="application" for the entire
> >>>>>> thing so we
> >>>>> can
> >>>>>> control keyboard behavior throughout the product.
> >>>>>>
> >>>>>> The idea we are going with is to have 4 panels the user can
> >>>>>> switch
> >>>>> between:
> >>>>>>
> >>>>>> - Toolbar (at the top)
> >>>>>> - Control Panel (on the left)
> >>>>>> - Properties Panel (on the right)
> >>>>>> - the main working canvas (in the middle)
> >>>>>>
> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
> >>>>>> has a
> >>>>> <span>
> >>>>>> with an offscreen class, which labels the panel. We put an
> >>>>> aria-labelledby
> >>>>>> attribute on the outermost element of the panel which links the
> >>>>> descriptive
> >>>>>> span.
> >>>>>>
> >>>>>> For example:
> >>>>>>
> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
> >>>>>> </section>
> >>>>>>
> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
> Group,
> >>>>> which
> >>>>>> makes sense, but it wont announce the "Toolbar" part.
> >>>>>>
> >>>>>> We've tried using aria-describedby, aria-label, and a regular
> >>>>>> old title attribute. The only thing that works is
> >>>>>> aria-labelledby with Jaws,
> >>>>> nothing
> >>>>>> on Mac.
> >>>>>>
> >>>>>> Any experience with this sort of problem? Possible solutions?
> >>>>>>
> >>>>>> Or did i just start myself a blog post? :)
> >>>>>>
> >>>>>> Happy Global Accessibility Awareness Day everyone!
> >>>>>>
> >>>>>> Jesse
> >>>>>> > >>>>>> > >>>>>> > >>>>>
> >>>>> > >>>>> > >>>>> > >>>>>
> >>>> > >>>> > >>>> > >>>
> >>> > >>> > >>> list messages to = EMAIL ADDRESS REMOVED =
> >>>
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
> >
>
>
> --
> Work hard. Have fun. Make history.
> > > list messages to = EMAIL ADDRESS REMOVED =
>
messages to = EMAIL ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Sat, May 17 2014 8:30AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Hi

role='document' is necessary when you have static content (content
that would not be read in context of focusable components"
So if the app has text that is not read as part of a focusable control
)think instructions, 'about this app' etc.= such text needs to have
role="document".

Apple does not consider role="region" as an actual landmark, which is
consistent with the ARIA spec.
Voiceover will announced the labeled region when user enters and exits
the reason during linear navigation, but user is not able to navigate
directly to that region e.g. when using the roater.
I am preparing to file a "bug"/"feature request" with Voiceover that
labeled regions be added as part of the accessibility roater and that
users will be able to navigate to it.
By labeled region I mean a div or a section element that has been
explicitly labeled using either aria-labelledby or aria-label.
I believe Voiceover supports most of the standard landmarks )"main",
"contentinfo" "banner" "navigation" "search" "form"), but I would need
to test it explicitly to give you a 100% accurate answer.


On 5/16/14, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> [Jesse wrote] Btw, do you know what apple considers a proper landmark? Is
> there a resource you can share?
>
> I've noticed inconsistencies with other screen readers too. For example,
> NVDA will announce ARIA landmarks and move to them with the d keystroke --
> however, HTML5 elements such as nav and aside which have direct ARIA
> landmark equivalents are not considered landmarks. This is unfortunate
> and causes people to add ARIA roles to native HTML5 code.
>
> Jonathan
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse Hausler
> Sent: Friday, May 16, 2014 1:49 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Announcing Region Labels on OSX
>
> Bikir,
>
> This is an interesting point you make. Part of the reason for wrapping the
> entire product in role="application" is so we can follow a model similar
> to a microsoft or adobe style building tool.
>
> So you're suggesting that if one of our "panels" has a form inside. I
> should wrap the form in a div with role="document". That's fair enough,
> but would that limit our ability to have the F6 key control cycling
> through our panels?
>
> I'm going to test this out tomorrow. Thanks for the great insight!
>
> Btw, do you know what apple considers a proper landmark? Is there a
> resource you can share?
>
> Thanks,
> Jesse
>
>
> On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> role="region" is not considered a landmark by Apple. Therefore any
>> landmark navigation options in Voiceover do not include regions.
>> VO announces labels of named regions when user enters/leaves the
>> regions in course of normal linear navigation.
>>
>> A further thought on your application design, without having seen it
>> of course.
>> Make sure to wrap any static piece of content inside div with
>> role="application" in a container element with role="document".
>> In forms mode it is hard for screen reader users, particularly
>> Jaws/NVDA to navigate static piece of text.
>> This is particularly true with older versions of NVDA (versions prior
>> to 2014.1)where user is unable to switch to browse mode when inside
>> divs with role="application".
>> Cheers and good luck.
>>
>>
>> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> > have to use linear navigation to get to the container On May 15,
>> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>> wrote:
>> >
>> >> Paul,
>> >>
>> >> I tried adding role="region" aria-label="hello world" to our
> <section>.
>> >> It
>> >> actually didn't work for us on OSX in Chrome or Safari.
>> >>
>> >> I wonder if it has something to do with how one enters the region.
>> >>
>> >> Jesse
>> >>
>> >>
>> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
>> >>> sometimes and then the focus jumps to a random control since it
>> >>> can't get to the off screen text.
>> >>>
>> >>> VO OS X reads "Interact with HTML content Hello World region" for
>> >>> the below code:
>> >>>
>> >>> <section role="region" aria-label="Hello
>> >>> World"><p>Blah</p></section>
>> >>>
>> >>>
>> >>>
>> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
>> >>> < = EMAIL ADDRESS REMOVED = >
>> >>> wrote:
>> >>>
>> >>>> Thanks for the quick response Paul.
>> >>>>
>> >>>> So you're saying that adding role="region" with aria-label will
>> >>>> make this compatible with more screen readers? Since we already
>> >>>> tried
>> aria-label,
>> >>>> what does the role="region" add that would cause aria-label to
>> >>>> begin working?
>> >>>>
>> >>>> As an aside, would role="group" be more appropriate?
>> >>>>
>> >>>> Yes, we definitely understand the responsibility of the
>> >>>> application role and intend to use JS throughout to control
>> >>>> keyboard focus.
>> >>>>
>> >>>> At this point, we're still prototyping to see if this is the best
>> >>>> way forward.
>> >>>>
>> >>>> Tell me more about your concerns with visually hidden text. It's
>> >>>> a method we use extensively in our products.
>> >>>>
>> >>>> Jesse
>> >>>>
>> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
>> >>>> < = EMAIL ADDRESS REMOVED = >
>> >>> wrote:
>> >>>>
>> >>>>> I don't recommend using visually hidden text, you'll find this
>> >>>>> causes problems later down the road.
>> >>>>>
>> >>>>> For VO OS X you need to add a role=region and use an aria-label
>> >>>>> instead
>> >>> of
>> >>>>> visually hidden text.
>> >>>>>
>> >>>>> Role=application is a BIG responsibility! You have to control
>> >>>>> every keyboard key they press with JavaScript events.
>> >>>>>
>> >>>>> Is the user not going to need any heading quick navigation keys
>> >>>>> or other screen reader nav keys while using the application?
>> >>>>>
>> >>>>>
>> >>>>> Paul J. Adam
>> >>>>> Accessibility Evangelist
>> >>>>> www.deque.com
>> >>>>>
>> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
>> >>>>> < = EMAIL ADDRESS REMOVED = >
>> >>>>> wrote:
>> >>>>>
>> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
>> >>>>>> announce a descriptive title for a region.
>> >>>>>>
>> >>>>>> We're prototyping a builder type application. Think Visio, but
>> >>>>>> way
>> >>>>> simpler
>> >>>>>> / smaller feature set.
>> >>>>>>
>> >>>>>> We're planning to use the role="application" for the entire
>> >>>>>> thing so we
>> >>>>> can
>> >>>>>> control keyboard behavior throughout the product.
>> >>>>>>
>> >>>>>> The idea we are going with is to have 4 panels the user can
>> >>>>>> switch
>> >>>>> between:
>> >>>>>>
>> >>>>>> - Toolbar (at the top)
>> >>>>>> - Control Panel (on the left)
>> >>>>>> - Properties Panel (on the right)
>> >>>>>> - the main working canvas (in the middle)
>> >>>>>>
>> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
>> >>>>>> has a
>> >>>>> <span>
>> >>>>>> with an offscreen class, which labels the panel. We put an
>> >>>>> aria-labelledby
>> >>>>>> attribute on the outermost element of the panel which links the
>> >>>>> descriptive
>> >>>>>> span.
>> >>>>>>
>> >>>>>> For example:
>> >>>>>>
>> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
>> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
>> >>>>>> </section>
>> >>>>>>
>> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
>> Group,
>> >>>>> which
>> >>>>>> makes sense, but it wont announce the "Toolbar" part.
>> >>>>>>
>> >>>>>> We've tried using aria-describedby, aria-label, and a regular
>> >>>>>> old title attribute. The only thing that works is
>> >>>>>> aria-labelledby with Jaws,
>> >>>>> nothing
>> >>>>>> on Mac.
>> >>>>>>
>> >>>>>> Any experience with this sort of problem? Possible solutions?
>> >>>>>>
>> >>>>>> Or did i just start myself a blog post? :)
>> >>>>>>
>> >>>>>> Happy Global Accessibility Awareness Day everyone!
>> >>>>>>
>> >>>>>> Jesse
>> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>
>> >>>>> >> >>>>> >> >>>>> >> >>>>>
>> >>>> >> >>>> >> >>>> >> >>>
>> >>> >> >>> >> >>> list messages to = EMAIL ADDRESS REMOVED =
>> >>>
>> >> >> >> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >
>> > >> > >> > list messages to = EMAIL ADDRESS REMOVED =
>> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
> > > messages to = EMAIL ADDRESS REMOVED =
> > > >


--
Work hard. Have fun. Make history.

From: Gunderson, Jon R
Date: Mon, May 19 2014 7:41AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Brikir,

If you post a bug for region navigation in voice over, please send the link to the bug to this list so people can vote to support VO implementation.

Jon


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, May 17, 2014 9:31 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Announcing Region Labels on OSX

Hi

role='document' is necessary when you have static content (content that would not be read in context of focusable components"
So if the app has text that is not read as part of a focusable control )think instructions, 'about this app' etc.= such text needs to have role="document".

Apple does not consider role="region" as an actual landmark, which is consistent with the ARIA spec.
Voiceover will announced the labeled region when user enters and exits the reason during linear navigation, but user is not able to navigate directly to that region e.g. when using the roater.
I am preparing to file a "bug"/"feature request" with Voiceover that labeled regions be added as part of the accessibility roater and that users will be able to navigate to it.
By labeled region I mean a div or a section element that has been explicitly labeled using either aria-labelledby or aria-label.
I believe Voiceover supports most of the standard landmarks )"main", "contentinfo" "banner" "navigation" "search" "form"), but I would need to test it explicitly to give you a 100% accurate answer.


On 5/16/14, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> [Jesse wrote] Btw, do you know what apple considers a proper landmark?
> Is there a resource you can share?
>
> I've noticed inconsistencies with other screen readers too. For
> example, NVDA will announce ARIA landmarks and move to them with the d
> keystroke -- however, HTML5 elements such as nav and aside which have
> direct ARIA landmark equivalents are not considered landmarks. This
> is unfortunate and causes people to add ARIA roles to native HTML5 code.
>
> Jonathan
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse
> Hausler
> Sent: Friday, May 16, 2014 1:49 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Announcing Region Labels on OSX
>
> Bikir,
>
> This is an interesting point you make. Part of the reason for wrapping
> the entire product in role="application" is so we can follow a model
> similar to a microsoft or adobe style building tool.
>
> So you're suggesting that if one of our "panels" has a form inside. I
> should wrap the form in a div with role="document". That's fair
> enough, but would that limit our ability to have the F6 key control
> cycling through our panels?
>
> I'm going to test this out tomorrow. Thanks for the great insight!
>
> Btw, do you know what apple considers a proper landmark? Is there a
> resource you can share?
>
> Thanks,
> Jesse
>
>
> On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> role="region" is not considered a landmark by Apple. Therefore any
>> landmark navigation options in Voiceover do not include regions.
>> VO announces labels of named regions when user enters/leaves the
>> regions in course of normal linear navigation.
>>
>> A further thought on your application design, without having seen it
>> of course.
>> Make sure to wrap any static piece of content inside div with
>> role="application" in a container element with role="document".
>> In forms mode it is hard for screen reader users, particularly
>> Jaws/NVDA to navigate static piece of text.
>> This is particularly true with older versions of NVDA (versions prior
>> to 2014.1)where user is unable to switch to browse mode when inside
>> divs with role="application".
>> Cheers and good luck.
>>
>>
>> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> > have to use linear navigation to get to the container On May 15,
>> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>> wrote:
>> >
>> >> Paul,
>> >>
>> >> I tried adding role="region" aria-label="hello world" to our
> <section>.
>> >> It
>> >> actually didn't work for us on OSX in Chrome or Safari.
>> >>
>> >> I wonder if it has something to do with how one enters the region.
>> >>
>> >> Jesse
>> >>
>> >>
>> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam
>> >> < = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
>> >>> sometimes and then the focus jumps to a random control since it
>> >>> can't get to the off screen text.
>> >>>
>> >>> VO OS X reads "Interact with HTML content Hello World region" for
>> >>> the below code:
>> >>>
>> >>> <section role="region" aria-label="Hello
>> >>> World"><p>Blah</p></section>
>> >>>
>> >>>
>> >>>
>> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
>> >>> < = EMAIL ADDRESS REMOVED = >
>> >>> wrote:
>> >>>
>> >>>> Thanks for the quick response Paul.
>> >>>>
>> >>>> So you're saying that adding role="region" with aria-label will
>> >>>> make this compatible with more screen readers? Since we already
>> >>>> tried
>> aria-label,
>> >>>> what does the role="region" add that would cause aria-label to
>> >>>> begin working?
>> >>>>
>> >>>> As an aside, would role="group" be more appropriate?
>> >>>>
>> >>>> Yes, we definitely understand the responsibility of the
>> >>>> application role and intend to use JS throughout to control
>> >>>> keyboard focus.
>> >>>>
>> >>>> At this point, we're still prototyping to see if this is the
>> >>>> best way forward.
>> >>>>
>> >>>> Tell me more about your concerns with visually hidden text. It's
>> >>>> a method we use extensively in our products.
>> >>>>
>> >>>> Jesse
>> >>>>
>> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
>> >>>> < = EMAIL ADDRESS REMOVED = >
>> >>> wrote:
>> >>>>
>> >>>>> I don't recommend using visually hidden text, you'll find this
>> >>>>> causes problems later down the road.
>> >>>>>
>> >>>>> For VO OS X you need to add a role=region and use an aria-label
>> >>>>> instead
>> >>> of
>> >>>>> visually hidden text.
>> >>>>>
>> >>>>> Role=application is a BIG responsibility! You have to control
>> >>>>> every keyboard key they press with JavaScript events.
>> >>>>>
>> >>>>> Is the user not going to need any heading quick navigation keys
>> >>>>> or other screen reader nav keys while using the application?
>> >>>>>
>> >>>>>
>> >>>>> Paul J. Adam
>> >>>>> Accessibility Evangelist
>> >>>>> www.deque.com
>> >>>>>
>> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
>> >>>>> < = EMAIL ADDRESS REMOVED = >
>> >>>>> wrote:
>> >>>>>
>> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
>> >>>>>> announce a descriptive title for a region.
>> >>>>>>
>> >>>>>> We're prototyping a builder type application. Think Visio, but
>> >>>>>> way
>> >>>>> simpler
>> >>>>>> / smaller feature set.
>> >>>>>>
>> >>>>>> We're planning to use the role="application" for the entire
>> >>>>>> thing so we
>> >>>>> can
>> >>>>>> control keyboard behavior throughout the product.
>> >>>>>>
>> >>>>>> The idea we are going with is to have 4 panels the user can
>> >>>>>> switch
>> >>>>> between:
>> >>>>>>
>> >>>>>> - Toolbar (at the top)
>> >>>>>> - Control Panel (on the left)
>> >>>>>> - Properties Panel (on the right)
>> >>>>>> - the main working canvas (in the middle)
>> >>>>>>
>> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
>> >>>>>> has a
>> >>>>> <span>
>> >>>>>> with an offscreen class, which labels the panel. We put an
>> >>>>> aria-labelledby
>> >>>>>> attribute on the outermost element of the panel which links
>> >>>>>> the
>> >>>>> descriptive
>> >>>>>> span.
>> >>>>>>
>> >>>>>> For example:
>> >>>>>>
>> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
>> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
>> >>>>>> </section>
>> >>>>>>
>> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
>> Group,
>> >>>>> which
>> >>>>>> makes sense, but it wont announce the "Toolbar" part.
>> >>>>>>
>> >>>>>> We've tried using aria-describedby, aria-label, and a regular
>> >>>>>> old title attribute. The only thing that works is
>> >>>>>> aria-labelledby with Jaws,
>> >>>>> nothing
>> >>>>>> on Mac.
>> >>>>>>
>> >>>>>> Any experience with this sort of problem? Possible solutions?
>> >>>>>>
>> >>>>>> Or did i just start myself a blog post? :)
>> >>>>>>
>> >>>>>> Happy Global Accessibility Awareness Day everyone!
>> >>>>>>
>> >>>>>> Jesse
>> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>
>> >>>>> >> >>>>> >> >>>>> >> >>>>>
>> >>>> >> >>>> >> >>>> >> >>>
>> >>> >> >>> >> >>> >> >>>
>> >> >> >> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >
>> > >> > >> > list messages to = EMAIL ADDRESS REMOVED =
>> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
> > > list messages to = EMAIL ADDRESS REMOVED =
> > > list messages to = EMAIL ADDRESS REMOVED =
>


--
Work hard. Have fun. Make history.

From: Birkir R. Gunnarsson
Date: Mon, May 19 2014 8:38AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Absolutely, I will.
I ahve discussed the potential bug filing with a certain member of the
PFWG who works for Apple (and whose email address should not be known
as it is not a place to file bugs), and he thinks it is a valid bug to
submit, whatever Apple decides to do in response.
I will get this ball rolling in the next couple of days, and will post
back to this list as requested.
Thanks
-Birkir


On 5/19/14, Gunderson, Jon R < = EMAIL ADDRESS REMOVED = > wrote:
> Brikir,
>
> If you post a bug for region navigation in voice over, please send the link
> to the bug to this list so people can vote to support VO implementation.
>
> Jon
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R.
> Gunnarsson
> Sent: Saturday, May 17, 2014 9:31 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Announcing Region Labels on OSX
>
> Hi
>
> role='document' is necessary when you have static content (content that
> would not be read in context of focusable components"
> So if the app has text that is not read as part of a focusable control
> )think instructions, 'about this app' etc.= such text needs to have
> role="document".
>
> Apple does not consider role="region" as an actual landmark, which is
> consistent with the ARIA spec.
> Voiceover will announced the labeled region when user enters and exits the
> reason during linear navigation, but user is not able to navigate directly
> to that region e.g. when using the roater.
> I am preparing to file a "bug"/"feature request" with Voiceover that labeled
> regions be added as part of the accessibility roater and that users will be
> able to navigate to it.
> By labeled region I mean a div or a section element that has been explicitly
> labeled using either aria-labelledby or aria-label.
> I believe Voiceover supports most of the standard landmarks )"main",
> "contentinfo" "banner" "navigation" "search" "form"), but I would need to
> test it explicitly to give you a 100% accurate answer.
>
>
> On 5/16/14, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> [Jesse wrote] Btw, do you know what apple considers a proper landmark?
>> Is there a resource you can share?
>>
>> I've noticed inconsistencies with other screen readers too. For
>> example, NVDA will announce ARIA landmarks and move to them with the d
>> keystroke -- however, HTML5 elements such as nav and aside which have
>> direct ARIA landmark equivalents are not considered landmarks. This
>> is unfortunate and causes people to add ARIA roles to native HTML5 code.
>>
>> Jonathan
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse
>> Hausler
>> Sent: Friday, May 16, 2014 1:49 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Announcing Region Labels on OSX
>>
>> Bikir,
>>
>> This is an interesting point you make. Part of the reason for wrapping
>> the entire product in role="application" is so we can follow a model
>> similar to a microsoft or adobe style building tool.
>>
>> So you're suggesting that if one of our "panels" has a form inside. I
>> should wrap the form in a div with role="document". That's fair
>> enough, but would that limit our ability to have the F6 key control
>> cycling through our panels?
>>
>> I'm going to test this out tomorrow. Thanks for the great insight!
>>
>> Btw, do you know what apple considers a proper landmark? Is there a
>> resource you can share?
>>
>> Thanks,
>> Jesse
>>
>>
>> On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> role="region" is not considered a landmark by Apple. Therefore any
>>> landmark navigation options in Voiceover do not include regions.
>>> VO announces labels of named regions when user enters/leaves the
>>> regions in course of normal linear navigation.
>>>
>>> A further thought on your application design, without having seen it
>>> of course.
>>> Make sure to wrap any static piece of content inside div with
>>> role="application" in a container element with role="document".
>>> In forms mode it is hard for screen reader users, particularly
>>> Jaws/NVDA to navigate static piece of text.
>>> This is particularly true with older versions of NVDA (versions prior
>>> to 2014.1)where user is unable to switch to browse mode when inside
>>> divs with role="application".
>>> Cheers and good luck.
>>>
>>>
>>> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>> > have to use linear navigation to get to the container On May 15,
>>> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>> >
>>> >> Paul,
>>> >>
>>> >> I tried adding role="region" aria-label="hello world" to our
>> <section>.
>>> >> It
>>> >> actually didn't work for us on OSX in Chrome or Safari.
>>> >>
>>> >> I wonder if it has something to do with how one enters the region.
>>> >>
>>> >> Jesse
>>> >>
>>> >>
>>> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam
>>> >> < = EMAIL ADDRESS REMOVED = >
>>> >> wrote:
>>> >>
>>> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
>>> >>> sometimes and then the focus jumps to a random control since it
>>> >>> can't get to the off screen text.
>>> >>>
>>> >>> VO OS X reads "Interact with HTML content Hello World region" for
>>> >>> the below code:
>>> >>>
>>> >>> <section role="region" aria-label="Hello
>>> >>> World"><p>Blah</p></section>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
>>> >>> < = EMAIL ADDRESS REMOVED = >
>>> >>> wrote:
>>> >>>
>>> >>>> Thanks for the quick response Paul.
>>> >>>>
>>> >>>> So you're saying that adding role="region" with aria-label will
>>> >>>> make this compatible with more screen readers? Since we already
>>> >>>> tried
>>> aria-label,
>>> >>>> what does the role="region" add that would cause aria-label to
>>> >>>> begin working?
>>> >>>>
>>> >>>> As an aside, would role="group" be more appropriate?
>>> >>>>
>>> >>>> Yes, we definitely understand the responsibility of the
>>> >>>> application role and intend to use JS throughout to control
>>> >>>> keyboard focus.
>>> >>>>
>>> >>>> At this point, we're still prototyping to see if this is the
>>> >>>> best way forward.
>>> >>>>
>>> >>>> Tell me more about your concerns with visually hidden text. It's
>>> >>>> a method we use extensively in our products.
>>> >>>>
>>> >>>> Jesse
>>> >>>>
>>> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
>>> >>>> < = EMAIL ADDRESS REMOVED = >
>>> >>> wrote:
>>> >>>>
>>> >>>>> I don't recommend using visually hidden text, you'll find this
>>> >>>>> causes problems later down the road.
>>> >>>>>
>>> >>>>> For VO OS X you need to add a role=region and use an aria-label
>>> >>>>> instead
>>> >>> of
>>> >>>>> visually hidden text.
>>> >>>>>
>>> >>>>> Role=application is a BIG responsibility! You have to control
>>> >>>>> every keyboard key they press with JavaScript events.
>>> >>>>>
>>> >>>>> Is the user not going to need any heading quick navigation keys
>>> >>>>> or other screen reader nav keys while using the application?
>>> >>>>>
>>> >>>>>
>>> >>>>> Paul J. Adam
>>> >>>>> Accessibility Evangelist
>>> >>>>> www.deque.com
>>> >>>>>
>>> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
>>> >>>>> < = EMAIL ADDRESS REMOVED = >
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
>>> >>>>>> announce a descriptive title for a region.
>>> >>>>>>
>>> >>>>>> We're prototyping a builder type application. Think Visio, but
>>> >>>>>> way
>>> >>>>> simpler
>>> >>>>>> / smaller feature set.
>>> >>>>>>
>>> >>>>>> We're planning to use the role="application" for the entire
>>> >>>>>> thing so we
>>> >>>>> can
>>> >>>>>> control keyboard behavior throughout the product.
>>> >>>>>>
>>> >>>>>> The idea we are going with is to have 4 panels the user can
>>> >>>>>> switch
>>> >>>>> between:
>>> >>>>>>
>>> >>>>>> - Toolbar (at the top)
>>> >>>>>> - Control Panel (on the left)
>>> >>>>>> - Properties Panel (on the right)
>>> >>>>>> - the main working canvas (in the middle)
>>> >>>>>>
>>> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
>>> >>>>>> has a
>>> >>>>> <span>
>>> >>>>>> with an offscreen class, which labels the panel. We put an
>>> >>>>> aria-labelledby
>>> >>>>>> attribute on the outermost element of the panel which links
>>> >>>>>> the
>>> >>>>> descriptive
>>> >>>>>> span.
>>> >>>>>>
>>> >>>>>> For example:
>>> >>>>>>
>>> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
>>> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
>>> >>>>>> </section>
>>> >>>>>>
>>> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
>>> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
>>> Group,
>>> >>>>> which
>>> >>>>>> makes sense, but it wont announce the "Toolbar" part.
>>> >>>>>>
>>> >>>>>> We've tried using aria-describedby, aria-label, and a regular
>>> >>>>>> old title attribute. The only thing that works is
>>> >>>>>> aria-labelledby with Jaws,
>>> >>>>> nothing
>>> >>>>>> on Mac.
>>> >>>>>>
>>> >>>>>> Any experience with this sort of problem? Possible solutions?
>>> >>>>>>
>>> >>>>>> Or did i just start myself a blog post? :)
>>> >>>>>>
>>> >>>>>> Happy Global Accessibility Awareness Day everyone!
>>> >>>>>>
>>> >>>>>> Jesse
>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>
>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>
>>> >>>> >>> >>>> >>> >>>> >>> >>>
>>> >>> >>> >>> >>> >>> >>> >>>
>>> >> >>> >> >>> >> list messages to = EMAIL ADDRESS REMOVED =
>>> >
>>> > >>> > >>> > list messages to = EMAIL ADDRESS REMOVED =
>>> >
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
>
> --
> Work hard. Have fun. Make history.
> > > messages to = EMAIL ADDRESS REMOVED =
> > > >


--
Work hard. Have fun. Make history.

From: Jesse Hausler
Date: Mon, May 19 2014 11:36AM
Subject: Re: Announcing Region Labels on OSX
← Previous message | Next message →

Glad to hear about the bug filing. That will be great to have.

As an update to the prototype we're working on, based on the info here,
we've dropped the role="application" altogether. We're going to let our
tabsets and menus apply their own application attributes and go from there.
Should be much better, with less margin of error.

On a related note, does F6 make sense as the key to rotate through panels?
We took this from MS products, but aren't sure if there is a more widely
used keystroke for panel navigation.

Thanks again,
Jesse


On Mon, May 19, 2014 at 7:38 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Absolutely, I will.
> I ahve discussed the potential bug filing with a certain member of the
> PFWG who works for Apple (and whose email address should not be known
> as it is not a place to file bugs), and he thinks it is a valid bug to
> submit, whatever Apple decides to do in response.
> I will get this ball rolling in the next couple of days, and will post
> back to this list as requested.
> Thanks
> -Birkir
>
>
> On 5/19/14, Gunderson, Jon R < = EMAIL ADDRESS REMOVED = > wrote:
> > Brikir,
> >
> > If you post a bug for region navigation in voice over, please send the
> link
> > to the bug to this list so people can vote to support VO implementation.
> >
> > Jon
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R.
> > Gunnarsson
> > Sent: Saturday, May 17, 2014 9:31 AM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Announcing Region Labels on OSX
> >
> > Hi
> >
> > role='document' is necessary when you have static content (content that
> > would not be read in context of focusable components"
> > So if the app has text that is not read as part of a focusable control
> > )think instructions, 'about this app' etc.= such text needs to have
> > role="document".
> >
> > Apple does not consider role="region" as an actual landmark, which is
> > consistent with the ARIA spec.
> > Voiceover will announced the labeled region when user enters and exits
> the
> > reason during linear navigation, but user is not able to navigate
> directly
> > to that region e.g. when using the roater.
> > I am preparing to file a "bug"/"feature request" with Voiceover that
> labeled
> > regions be added as part of the accessibility roater and that users will
> be
> > able to navigate to it.
> > By labeled region I mean a div or a section element that has been
> explicitly
> > labeled using either aria-labelledby or aria-label.
> > I believe Voiceover supports most of the standard landmarks )"main",
> > "contentinfo" "banner" "navigation" "search" "form"), but I would need to
> > test it explicitly to give you a 100% accurate answer.
> >
> >
> > On 5/16/14, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> >> [Jesse wrote] Btw, do you know what apple considers a proper landmark?
> >> Is there a resource you can share?
> >>
> >> I've noticed inconsistencies with other screen readers too. For
> >> example, NVDA will announce ARIA landmarks and move to them with the d
> >> keystroke -- however, HTML5 elements such as nav and aside which have
> >> direct ARIA landmark equivalents are not considered landmarks. This
> >> is unfortunate and causes people to add ARIA roles to native HTML5 code.
> >>
> >> Jonathan
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse
> >> Hausler
> >> Sent: Friday, May 16, 2014 1:49 AM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Announcing Region Labels on OSX
> >>
> >> Bikir,
> >>
> >> This is an interesting point you make. Part of the reason for wrapping
> >> the entire product in role="application" is so we can follow a model
> >> similar to a microsoft or adobe style building tool.
> >>
> >> So you're suggesting that if one of our "panels" has a form inside. I
> >> should wrap the form in a div with role="document". That's fair
> >> enough, but would that limit our ability to have the F6 key control
> >> cycling through our panels?
> >>
> >> I'm going to test this out tomorrow. Thanks for the great insight!
> >>
> >> Btw, do you know what apple considers a proper landmark? Is there a
> >> resource you can share?
> >>
> >> Thanks,
> >> Jesse
> >>
> >>
> >> On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
> >> = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >>> role="region" is not considered a landmark by Apple. Therefore any
> >>> landmark navigation options in Voiceover do not include regions.
> >>> VO announces labels of named regions when user enters/leaves the
> >>> regions in course of normal linear navigation.
> >>>
> >>> A further thought on your application design, without having seen it
> >>> of course.
> >>> Make sure to wrap any static piece of content inside div with
> >>> role="application" in a container element with role="document".
> >>> In forms mode it is hard for screen reader users, particularly
> >>> Jaws/NVDA to navigate static piece of text.
> >>> This is particularly true with older versions of NVDA (versions prior
> >>> to 2014.1)where user is unable to switch to browse mode when inside
> >>> divs with role="application".
> >>> Cheers and good luck.
> >>>
> >>>
> >>> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> >>> > have to use linear navigation to get to the container On May 15,
> >>> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>> >
> >>> >> Paul,
> >>> >>
> >>> >> I tried adding role="region" aria-label="hello world" to our
> >> <section>.
> >>> >> It
> >>> >> actually didn't work for us on OSX in Chrome or Safari.
> >>> >>
> >>> >> I wonder if it has something to do with how one enters the region.
> >>> >>
> >>> >> Jesse
> >>> >>
> >>> >>
> >>> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam
> >>> >> < = EMAIL ADDRESS REMOVED = >
> >>> >> wrote:
> >>> >>
> >>> >>> VoiceOver for iOS tries to go focus on elements that are -9999px
> >>> >>> sometimes and then the focus jumps to a random control since it
> >>> >>> can't get to the off screen text.
> >>> >>>
> >>> >>> VO OS X reads "Interact with HTML content Hello World region" for
> >>> >>> the below code:
> >>> >>>
> >>> >>> <section role="region" aria-label="Hello
> >>> >>> World"><p>Blah</p></section>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
> >>> >>> < = EMAIL ADDRESS REMOVED = >
> >>> >>> wrote:
> >>> >>>
> >>> >>>> Thanks for the quick response Paul.
> >>> >>>>
> >>> >>>> So you're saying that adding role="region" with aria-label will
> >>> >>>> make this compatible with more screen readers? Since we already
> >>> >>>> tried
> >>> aria-label,
> >>> >>>> what does the role="region" add that would cause aria-label to
> >>> >>>> begin working?
> >>> >>>>
> >>> >>>> As an aside, would role="group" be more appropriate?
> >>> >>>>
> >>> >>>> Yes, we definitely understand the responsibility of the
> >>> >>>> application role and intend to use JS throughout to control
> >>> >>>> keyboard focus.
> >>> >>>>
> >>> >>>> At this point, we're still prototyping to see if this is the
> >>> >>>> best way forward.
> >>> >>>>
> >>> >>>> Tell me more about your concerns with visually hidden text. It's
> >>> >>>> a method we use extensively in our products.
> >>> >>>>
> >>> >>>> Jesse
> >>> >>>>
> >>> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
> >>> >>>> < = EMAIL ADDRESS REMOVED = >
> >>> >>> wrote:
> >>> >>>>
> >>> >>>>> I don't recommend using visually hidden text, you'll find this
> >>> >>>>> causes problems later down the road.
> >>> >>>>>
> >>> >>>>> For VO OS X you need to add a role=region and use an aria-label
> >>> >>>>> instead
> >>> >>> of
> >>> >>>>> visually hidden text.
> >>> >>>>>
> >>> >>>>> Role=application is a BIG responsibility! You have to control
> >>> >>>>> every keyboard key they press with JavaScript events.
> >>> >>>>>
> >>> >>>>> Is the user not going to need any heading quick navigation keys
> >>> >>>>> or other screen reader nav keys while using the application?
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> Paul J. Adam
> >>> >>>>> Accessibility Evangelist
> >>> >>>>> www.deque.com
> >>> >>>>>
> >>> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
> >>> >>>>> < = EMAIL ADDRESS REMOVED = >
> >>> >>>>> wrote:
> >>> >>>>>
> >>> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
> >>> >>>>>> announce a descriptive title for a region.
> >>> >>>>>>
> >>> >>>>>> We're prototyping a builder type application. Think Visio, but
> >>> >>>>>> way
> >>> >>>>> simpler
> >>> >>>>>> / smaller feature set.
> >>> >>>>>>
> >>> >>>>>> We're planning to use the role="application" for the entire
> >>> >>>>>> thing so we
> >>> >>>>> can
> >>> >>>>>> control keyboard behavior throughout the product.
> >>> >>>>>>
> >>> >>>>>> The idea we are going with is to have 4 panels the user can
> >>> >>>>>> switch
> >>> >>>>> between:
> >>> >>>>>>
> >>> >>>>>> - Toolbar (at the top)
> >>> >>>>>> - Control Panel (on the left)
> >>> >>>>>> - Properties Panel (on the right)
> >>> >>>>>> - the main working canvas (in the middle)
> >>> >>>>>>
> >>> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each panel
> >>> >>>>>> has a
> >>> >>>>> <span>
> >>> >>>>>> with an offscreen class, which labels the panel. We put an
> >>> >>>>> aria-labelledby
> >>> >>>>>> attribute on the outermost element of the panel which links
> >>> >>>>>> the
> >>> >>>>> descriptive
> >>> >>>>>> span.
> >>> >>>>>>
> >>> >>>>>> For example:
> >>> >>>>>>
> >>> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
> >>> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
> >>> >>>>>> </section>
> >>> >>>>>>
> >>> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>> >>>>>> VoiceOver with both Safari and Chrome will state that his is a
> >>> Group,
> >>> >>>>> which
> >>> >>>>>> makes sense, but it wont announce the "Toolbar" part.
> >>> >>>>>>
> >>> >>>>>> We've tried using aria-describedby, aria-label, and a regular
> >>> >>>>>> old title attribute. The only thing that works is
> >>> >>>>>> aria-labelledby with Jaws,
> >>> >>>>> nothing
> >>> >>>>>> on Mac.
> >>> >>>>>>
> >>> >>>>>> Any experience with this sort of problem? Possible solutions?
> >>> >>>>>>
> >>> >>>>>> Or did i just start myself a blog post? :)
> >>> >>>>>>
> >>> >>>>>> Happy Global Accessibility Awareness Day everyone!
> >>> >>>>>>
> >>> >>>>>> Jesse
> >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>
> >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>
> >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>
> >>> >>> > >>> >>> > >>> >>> > >>> >>>
> >>> >> > >>> >> > >>> >> list messages to = EMAIL ADDRESS REMOVED =
> >>> >
> >>> > > >>> > > >>> > list messages to = EMAIL ADDRESS REMOVED =
> >>> >
> >>>
> >>>
> >>> --
> >>> Work hard. Have fun. Make history.
> >>> > >>> > >>> list messages to = EMAIL ADDRESS REMOVED =
> >>>
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >>
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > messages to = EMAIL ADDRESS REMOVED =
> > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > >

From: Bryan Garaventa
Date: Mon, May 19 2014 12:28PM
Subject: Re: Announcing Region Labels on OSX
← Previous message | No next message

I don't recommend f6, simply because it conflicts with the browser hotkey
for quickly jumping between browser panels, such as between the address bar,
browser window, and so on. The trick is picking a keystroke that doesn't
conflict with native functionality.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse Hausler
Sent: Monday, May 19, 2014 10:36 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Announcing Region Labels on OSX

Glad to hear about the bug filing. That will be great to have.

As an update to the prototype we're working on, based on the info here,
we've dropped the role="application" altogether. We're going to let our
tabsets and menus apply their own application attributes and go from there.
Should be much better, with less margin of error.

On a related note, does F6 make sense as the key to rotate through panels?
We took this from MS products, but aren't sure if there is a more widely
used keystroke for panel navigation.

Thanks again,
Jesse


On Mon, May 19, 2014 at 7:38 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Absolutely, I will.
> I ahve discussed the potential bug filing with a certain member of the
> PFWG who works for Apple (and whose email address should not be known
> as it is not a place to file bugs), and he thinks it is a valid bug to
> submit, whatever Apple decides to do in response.
> I will get this ball rolling in the next couple of days, and will post
> back to this list as requested.
> Thanks
> -Birkir
>
>
> On 5/19/14, Gunderson, Jon R < = EMAIL ADDRESS REMOVED = > wrote:
> > Brikir,
> >
> > If you post a bug for region navigation in voice over, please send
> > the
> link
> > to the bug to this list so people can vote to support VO implementation.
> >
> > Jon
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R.
> > Gunnarsson
> > Sent: Saturday, May 17, 2014 9:31 AM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Announcing Region Labels on OSX
> >
> > Hi
> >
> > role='document' is necessary when you have static content (content
> > that would not be read in context of focusable components"
> > So if the app has text that is not read as part of a focusable
> > control )think instructions, 'about this app' etc.= such text needs
> > to have role="document".
> >
> > Apple does not consider role="region" as an actual landmark, which
> > is consistent with the ARIA spec.
> > Voiceover will announced the labeled region when user enters and
> > exits
> the
> > reason during linear navigation, but user is not able to navigate
> directly
> > to that region e.g. when using the roater.
> > I am preparing to file a "bug"/"feature request" with Voiceover that
> labeled
> > regions be added as part of the accessibility roater and that users
> > will
> be
> > able to navigate to it.
> > By labeled region I mean a div or a section element that has been
> explicitly
> > labeled using either aria-labelledby or aria-label.
> > I believe Voiceover supports most of the standard landmarks )"main",
> > "contentinfo" "banner" "navigation" "search" "form"), but I would
> > need to test it explicitly to give you a 100% accurate answer.
> >
> >
> > On 5/16/14, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> >> [Jesse wrote] Btw, do you know what apple considers a proper landmark?
> >> Is there a resource you can share?
> >>
> >> I've noticed inconsistencies with other screen readers too. For
> >> example, NVDA will announce ARIA landmarks and move to them with
> >> the d keystroke -- however, HTML5 elements such as nav and aside
> >> which have direct ARIA landmark equivalents are not considered
> >> landmarks. This is unfortunate and causes people to add ARIA roles to
native HTML5 code.
> >>
> >> Jonathan
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jesse
> >> Hausler
> >> Sent: Friday, May 16, 2014 1:49 AM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Announcing Region Labels on OSX
> >>
> >> Bikir,
> >>
> >> This is an interesting point you make. Part of the reason for
> >> wrapping the entire product in role="application" is so we can
> >> follow a model similar to a microsoft or adobe style building tool.
> >>
> >> So you're suggesting that if one of our "panels" has a form inside.
> >> I should wrap the form in a div with role="document". That's fair
> >> enough, but would that limit our ability to have the F6 key control
> >> cycling through our panels?
> >>
> >> I'm going to test this out tomorrow. Thanks for the great insight!
> >>
> >> Btw, do you know what apple considers a proper landmark? Is there
> >> a resource you can share?
> >>
> >> Thanks,
> >> Jesse
> >>
> >>
> >> On Thu, May 15, 2014 at 6:29 PM, Birkir R. Gunnarsson <
> >> = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >>> role="region" is not considered a landmark by Apple. Therefore any
> >>> landmark navigation options in Voiceover do not include regions.
> >>> VO announces labels of named regions when user enters/leaves the
> >>> regions in course of normal linear navigation.
> >>>
> >>> A further thought on your application design, without having seen
> >>> it of course.
> >>> Make sure to wrap any static piece of content inside div with
> >>> role="application" in a container element with role="document".
> >>> In forms mode it is hard for screen reader users, particularly
> >>> Jaws/NVDA to navigate static piece of text.
> >>> This is particularly true with older versions of NVDA (versions
> >>> prior to 2014.1)where user is unable to switch to browse mode when
> >>> inside divs with role="application".
> >>> Cheers and good luck.
> >>>
> >>>
> >>> On 5/15/14, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> >>> > have to use linear navigation to get to the container On May 15,
> >>> > 2014, at 7:38 PM, Jesse Hausler < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>> >
> >>> >> Paul,
> >>> >>
> >>> >> I tried adding role="region" aria-label="hello world" to our
> >> <section>.
> >>> >> It
> >>> >> actually didn't work for us on OSX in Chrome or Safari.
> >>> >>
> >>> >> I wonder if it has something to do with how one enters the region.
> >>> >>
> >>> >> Jesse
> >>> >>
> >>> >>
> >>> >> On Thu, May 15, 2014 at 1:44 PM, Paul J. Adam
> >>> >> < = EMAIL ADDRESS REMOVED = >
> >>> >> wrote:
> >>> >>
> >>> >>> VoiceOver for iOS tries to go focus on elements that are
> >>> >>> -9999px sometimes and then the focus jumps to a random control
> >>> >>> since it can't get to the off screen text.
> >>> >>>
> >>> >>> VO OS X reads "Interact with HTML content Hello World region"
> >>> >>> for the below code:
> >>> >>>
> >>> >>> <section role="region" aria-label="Hello
> >>> >>> World"><p>Blah</p></section>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On May 15, 2014, at 3:36 PM, Jesse Hausler
> >>> >>> < = EMAIL ADDRESS REMOVED = >
> >>> >>> wrote:
> >>> >>>
> >>> >>>> Thanks for the quick response Paul.
> >>> >>>>
> >>> >>>> So you're saying that adding role="region" with aria-label
> >>> >>>> will make this compatible with more screen readers? Since we
> >>> >>>> already tried
> >>> aria-label,
> >>> >>>> what does the role="region" add that would cause aria-label
> >>> >>>> to begin working?
> >>> >>>>
> >>> >>>> As an aside, would role="group" be more appropriate?
> >>> >>>>
> >>> >>>> Yes, we definitely understand the responsibility of the
> >>> >>>> application role and intend to use JS throughout to control
> >>> >>>> keyboard focus.
> >>> >>>>
> >>> >>>> At this point, we're still prototyping to see if this is the
> >>> >>>> best way forward.
> >>> >>>>
> >>> >>>> Tell me more about your concerns with visually hidden text.
> >>> >>>> It's a method we use extensively in our products.
> >>> >>>>
> >>> >>>> Jesse
> >>> >>>>
> >>> >>>> On Thu, May 15, 2014 at 1:16 PM, Paul J. Adam
> >>> >>>> < = EMAIL ADDRESS REMOVED = >
> >>> >>> wrote:
> >>> >>>>
> >>> >>>>> I don't recommend using visually hidden text, you'll find
> >>> >>>>> this causes problems later down the road.
> >>> >>>>>
> >>> >>>>> For VO OS X you need to add a role=region and use an
> >>> >>>>> aria-label instead
> >>> >>> of
> >>> >>>>> visually hidden text.
> >>> >>>>>
> >>> >>>>> Role=application is a BIG responsibility! You have to
> >>> >>>>> control every keyboard key they press with JavaScript events.
> >>> >>>>>
> >>> >>>>> Is the user not going to need any heading quick navigation
> >>> >>>>> keys or other screen reader nav keys while using the
application?
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> Paul J. Adam
> >>> >>>>> Accessibility Evangelist
> >>> >>>>> www.deque.com
> >>> >>>>>
> >>> >>>>> On May 15, 2014, at 2:56 PM, Jesse Hausler
> >>> >>>>> < = EMAIL ADDRESS REMOVED = >
> >>> >>>>> wrote:
> >>> >>>>>
> >>> >>>>>> I'm having trouble using ARIA to get VoiceOver on OSX to
> >>> >>>>>> announce a descriptive title for a region.
> >>> >>>>>>
> >>> >>>>>> We're prototyping a builder type application. Think Visio,
> >>> >>>>>> but way
> >>> >>>>> simpler
> >>> >>>>>> / smaller feature set.
> >>> >>>>>>
> >>> >>>>>> We're planning to use the role="application" for the entire
> >>> >>>>>> thing so we
> >>> >>>>> can
> >>> >>>>>> control keyboard behavior throughout the product.
> >>> >>>>>>
> >>> >>>>>> The idea we are going with is to have 4 panels the user can
> >>> >>>>>> switch
> >>> >>>>> between:
> >>> >>>>>>
> >>> >>>>>> - Toolbar (at the top)
> >>> >>>>>> - Control Panel (on the left)
> >>> >>>>>> - Properties Panel (on the right)
> >>> >>>>>> - the main working canvas (in the middle)
> >>> >>>>>>
> >>> >>>>>> F6 and Shift+F6 move the user from panel to panel. Each
> >>> >>>>>> panel has a
> >>> >>>>> <span>
> >>> >>>>>> with an offscreen class, which labels the panel. We put an
> >>> >>>>> aria-labelledby
> >>> >>>>>> attribute on the outermost element of the panel which links
> >>> >>>>>> the
> >>> >>>>> descriptive
> >>> >>>>>> span.
> >>> >>>>>>
> >>> >>>>>> For example:
> >>> >>>>>>
> >>> >>>>>> <section aria-labelledy="tbar"> <span class="assistiveText"
> >>> >>>>>> id="tbar">Toolbar</span> ... rest of the panel content...
> >>> >>>>>> </section>
> >>> >>>>>>
> >>> >>>>>> I get proper feedback using Jaws and FF: "Toolbar region..."
> >>> >>>>>> VoiceOver with both Safari and Chrome will state that his
> >>> >>>>>> is a
> >>> Group,
> >>> >>>>> which
> >>> >>>>>> makes sense, but it wont announce the "Toolbar" part.
> >>> >>>>>>
> >>> >>>>>> We've tried using aria-describedby, aria-label, and a
> >>> >>>>>> regular old title attribute. The only thing that works is
> >>> >>>>>> aria-labelledby with Jaws,
> >>> >>>>> nothing
> >>> >>>>>> on Mac.
> >>> >>>>>>
> >>> >>>>>> Any experience with this sort of problem? Possible solutions?
> >>> >>>>>>
> >>> >>>>>> Or did i just start myself a blog post? :)
> >>> >>>>>>
> >>> >>>>>> Happy Global Accessibility Awareness Day everyone!
> >>> >>>>>>
> >>> >>>>>> Jesse
> >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>
> >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>
> >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>
> >>> >>> > >>> >>> > >>> >>> > >>> >>>
> >>> >> > >>> >> > >>> >> > >>> >
> >>> > > >>> > > >>> > > >>> >
> >>>
> >>>
> >>> --
> >>> Work hard. Have fun. Make history.
> >>> > >>> > >>> list messages to = EMAIL ADDRESS REMOVED =
> >>>
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >> > >> > >> list messages to = EMAIL ADDRESS REMOVED =
> >>
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
> >
>
>
> --
> Work hard. Have fun. Make history.
> > > list messages to = EMAIL ADDRESS REMOVED =
>
messages to = EMAIL ADDRESS REMOVED =