E-mail List Archives

Search E-mail List Archives for

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

From: Detlev Fischer
Date: Thu, Aug 06 2015 6:54AM
Subject: tabpanel mark-up, possible effect of role=presentation
No previous message | Next message →

Hi,

I have a question for screen reader users. Curently I am testing a site that uses what appears to be a properly marked-up tabpanel: two tabs with role tab, content in two divs with role tabpanel. The tabs are technically skip links to the associated tabpanel divs. These two tab links sit inside li elements with role=presentation. The site also use aria-selected on the tabs and aria-hidden=true and display=none on the hidden tabpanel.

Now my question: when navigating with arrow keys in NVDA and JAWS (Firefox), both screen readers do not read the tabs - they skip straight to the tabpanel content below. I fist though this might be due to role=presentatino on the li elements, but this role should not apply to the a elements inside the li elements, if I correctly understand the ARIA semantics.

Tabbing through content will focus and rtead the tabs, but fail to read the tabpanel content when arrowing doen after activation (just a visible scroll effect).
Could well be that I am not using the screen readers correctly. Or is this due to known screen reader bugs?
Unfortunately I cannot point you to the site (behind a login).

Any ideas?

--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)1577 170 73 84
Tel +49 (0)40 439 10 68-3
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

From: Birkir R. Gunnarsson
Date: Thu, Aug 06 2015 7:33AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Hi

This sounds like the site is using some Javascript that does things it
should do.
The tab mak-up should be
<code>
<ul role="tablist">
<li role="presentation" aria-controls="tabp1" id="tab1"><a href="#"
role="tab" aria-selected="true">Tab 1</a></li>
<li role="presentation"><a href="#" tabindex="-1" role="tab"
aria-controls="tabp2">Tab 2</a></li>
....
</ul>
...
<div role="tabpanel" aria-labelldby="tab1" id="tab1" tabindex="-1">
..
</div>
</cide>

You use role tablist on the list containing the tabs.
YOu use role presentation on the li elements to enable screen readers
to calculate the number of tabs .. because the tabs should be direct
children of tablist (if you skip those the screen readers will read "1
of 1" for each tab, which is not the end of the world).
Only the active tab should be in taborder (hence abindex="-1" on other tabs).
You need JavaScript to implement the arrow key navigation.
When user navigates to a tab with the arrow key, the aria-selected
attribute should be moved and tabpanel content should become visible.
But focus should not be ripped away from the user and forced into the
content. The user might just be exploring what tabs are available,
that would be a WCAG 3.2.2 violation.
There are some example tab implementations with live example as well
as downloadable code on http://dequeuniversity.com (under "examples
and resources").
I am partially responsible for some of them, particularly the
responsive tabs to accordion example (tabs don't work well on phones
so we decided to think responsively .. just like we drink
responsibly).
Also check out the tabpanel example in the WAI-ARIA Authoring Best Practices.

And, remember, ARIA only tells screen reader what something is, it
does not make it act differently. All that is for the developers to
do.
If I say
<span role="link">Google</span>
it does not make the span focusable or take user to Google when user
clicks on it.
If you set a tabindex="0" on the span and associate JavaScript that
detected click events and took the user to Google, then you actually
have a link.
Now you are just lying to the (screen reader) user that your span is a link.
He will her the word "link" announced when he navigates with his arrow
keys in screenreader virtual buffer, but he cannot put focus on it or
activate it or anything.

Cheers
-B


On 8/6/15, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> I have a question for screen reader users. Curently I am testing a site that
> uses what appears to be a properly marked-up tabpanel: two tabs with role
> tab, content in two divs with role tabpanel. The tabs are technically skip
> links to the associated tabpanel divs. These two tab links sit inside li
> elements with role=presentation. The site also use aria-selected on the tabs
> and aria-hidden=true and display=none on the hidden tabpanel.
>
> Now my question: when navigating with arrow keys in NVDA and JAWS (Firefox),
> both screen readers do not read the tabs - they skip straight to the
> tabpanel content below. I fist though this might be due to role=presentatino
> on the li elements, but this role should not apply to the a elements inside
> the li elements, if I correctly understand the ARIA semantics.
>
> Tabbing through content will focus and rtead the tabs, but fail to read the
> tabpanel content when arrowing doen after activation (just a visible scroll
> effect).
> Could well be that I am not using the screen readers correctly. Or is this
> due to known screen reader bugs?
> Unfortunately I cannot point you to the site (behind a login).
>
> Any ideas?
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> > > > >


--
Work hard. Have fun. Make history.

From: Léonie Watson
Date: Thu, Aug 06 2015 8:03AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ]
> On Behalf Of Detlev Fischer
> Sent: 06 August 2015 13:55
> Now my question: when navigating with arrow keys in NVDA and JAWS
> (Firefox), both screen readers do not read the tabs - they skip straight to the
> tabpanel content below. I fist though this might be due to role=presentatino
> on the li elements, but this role should not apply to the a elements inside the
> li elements, if I correctly understand the ARIA semantics.

I've just tested the following code with NVDA and Jaws in FF. In each case the tabs are announced as expected. It's worth noting that when using the arrow keys to navigate, NVDA will speak both tabs as a single announcement, whereas Jaws will announce them separately (requiring an additional key press).

<ul role="tablist">
<li role="presentation"><a href="#p1" role="tab" aria-selected="true" aria-controls="p1" id="t1">Blanco</a></li>
<li role="presentation"><a href="p2" role="tab" aria-selected="false" aria-controls="p2" id="t2">Reposado</a></li>
</ul>

<div role="tabpanel" id="p1" aria-labelledby="t1" aria-hidden="false">Blanco tequila is...</div>
<div role="tabpanel" id="p2" aria-labelledby="t2" aria-hidden="true">Reposado tequila is...</div>

I think this code example matches the description of the code you're testing? If so, Birkir's suggestion that the JavaScript might be at fault is worth looking at, or alternatively check the styles. If you can cut/paste the HTML of the example you're looking at into an email, that might help us track it down though.

Léonie.


--
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

From: Jonathan Avila
Date: Thu, Aug 06 2015 8:30AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Detlev, perhaps aria-hidden is not being updated in time for the screen reader to see the updated content.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Detlev Fischer
Date: Thu, Aug 06 2015 9:52AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Hi,
thanks to Jon and Leonie and Birkir for your quick and helpful suggestions!

The main deviation from the recommended pattern is that on reaching the tablist, arrow navigation is not used to navigate between tabs - tabs are indeed reached by tabbing to them, and enter on the focused tab updates the tabpanel content. (We actually have at times recommended that behaviour to avoid a situation where users not familiar with the tab pattern and switching to arrowing may miss content inside not active tabpanels.)

Jon: the tabs themselves do not have aria-hidden on them, and they are the ones that are not read by the screenreader when arrowing through content...

What is missing in the current mark-up of tabs is actually the "aria-controls" attribute referencing the respective tabpanels. So adding that might make a difference.

Birkir: the ol holding the li elements witn role=presentation indeed carries role=tablist.

--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)1577 170 73 84
Tel +49 (0)40 439 10 68-3
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Jonathan Avila schrieb am 06.08.2015 16:30:

> Detlev, perhaps aria-hidden is not being updated in time for the screen reader
> to see the updated content.
>
> Jonathan
>
> -- 
> Jonathan Avila 
> Chief Accessibility Officer
> SSB BART Group 
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957  
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Birkir R. Gunnarsson
Date: Thu, Aug 06 2015 10:25AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Be mindful of using aria-hidden="false" as it may override things
inside the tabpanel that are supposed to be hidden.
<div role="tabpanel" aria-hidden="false">
<div id="userOpinionSecret" style="display: none">WE know this user,
he is not popular</div>
</div>
Users, at least of some screen readers, will see tthis text, because
aria-hidden="false" overrides display: none;
If you are using display: none type class to hide inactive tabpanels
you do not need to add aria-hidden to that.
I have passed tabbed interfaces where all tabs are in focus order,
though I have recommended full implementation as strong best practice.
Jaws treats tabs as comboboxes (you can get to them using keyboard
shortcut "c") and it makes sense in a way, but only if arrow key
navigation is enabled.
I would be surprised if adding aria-controls solves the issue, though
I hope it does.



On 8/6/15, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> thanks to Jon and Leonie and Birkir for your quick and helpful suggestions!
>
> The main deviation from the recommended pattern is that on reaching the
> tablist, arrow navigation is not used to navigate between tabs - tabs are
> indeed reached by tabbing to them, and enter on the focused tab updates the
> tabpanel content. (We actually have at times recommended that behaviour to
> avoid a situation where users not familiar with the tab pattern and
> switching to arrowing may miss content inside not active tabpanels.)
>
> Jon: the tabs themselves do not have aria-hidden on them, and they are the
> ones that are not read by the screenreader when arrowing through content...
>
> What is missing in the current mark-up of tabs is actually the
> "aria-controls" attribute referencing the respective tabpanels. So adding
> that might make a difference.
>
> Birkir: the ol holding the li elements witn role=presentation indeed carries
> role=tablist.
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> Jonathan Avila schrieb am 06.08.2015 16:30:
>
>> Detlev, perhaps aria-hidden is not being updated in time for the screen
>> reader
>> to see the updated content.
>>
>> Jonathan
>>
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> = EMAIL ADDRESS REMOVED =
>> Phone 703.637.8957
>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>>

From: Steve Faulkner
Date: Thu, Aug 06 2015 10:28AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

On 6 August 2015 at 17:25, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED =
> wrote:

> <div role="tabpanel" aria-hidden="false">
> <div id="userOpinionSecret" style="display: none">WE know this user,
> he is not popular</div>
> </div>
>

can you provide examples of AT/browser combinations where this is announced
by AT?

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Birkir R. Gunnarsson
Date: Thu, Aug 06 2015 10:49AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

This has been the case in iOS/Voiceover (last tested on iOS8.2 on iPhone/iPad).
I can throw together an example and retest, we have had a few upgrades.



On 8/6/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> On 6 August 2015 at 17:25, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED =
>> wrote:
>
>> <div role="tabpanel" aria-hidden="false">
>> <div id="userOpinionSecret" style="display: none">WE know this user,
>> he is not popular</div>
>> </div>
>>
>
> can you provide examples of AT/browser combinations where this is announced
> by AT?
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > >


--
Work hard. Have fun. Make history.

From: Graham Armfield
Date: Thu, Aug 06 2015 10:56AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Having all the tab headers as links surely helps users of Dragon
NaturallySpeaking to select required tab more easily - without having to
rely on mouse grid or full mouse move interaction. Also, aren't many switch
setups geared up for easier access to tab and enter - rather than
left/right arrow keys?

Regards
​Graham Armfield​



On Thu, Aug 6, 2015 at 5:25 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Be mindful of using aria-hidden="false" as it may override things
> inside the tabpanel that are supposed to be hidden.
> <div role="tabpanel" aria-hidden="false">
> <div id="userOpinionSecret" style="display: none">WE know this user,
> he is not popular</div>
> </div>
> Users, at least of some screen readers, will see tthis text, because
> aria-hidden="false" overrides display: none;
> If you are using display: none type class to hide inactive tabpanels
> you do not need to add aria-hidden to that.
> I have passed tabbed interfaces where all tabs are in focus order,
> though I have recommended full implementation as strong best practice.
> Jaws treats tabs as comboboxes (you can get to them using keyboard
> shortcut "c") and it makes sense in a way, but only if arrow key
> navigation is enabled.
> I would be surprised if adding aria-controls solves the issue, though
> I hope it does.
>
>
>
> On 8/6/15, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi,
> > thanks to Jon and Leonie and Birkir for your quick and helpful
> suggestions!
> >
> > The main deviation from the recommended pattern is that on reaching the
> > tablist, arrow navigation is not used to navigate between tabs - tabs are
> > indeed reached by tabbing to them, and enter on the focused tab updates
> the
> > tabpanel content. (We actually have at times recommended that behaviour
> to
> > avoid a situation where users not familiar with the tab pattern and
> > switching to arrowing may miss content inside not active tabpanels.)
> >
> > Jon: the tabs themselves do not have aria-hidden on them, and they are
> the
> > ones that are not read by the screenreader when arrowing through
> content...
> >
> > What is missing in the current mark-up of tabs is actually the
> > "aria-controls" attribute referencing the respective tabpanels. So adding
> > that might make a difference.
> >
> > Birkir: the ol holding the li elements witn role=presentation indeed
> carries
> > role=tablist.
> >
> > --
> > Detlev Fischer
> > testkreis c/o feld.wald.wiese
> > Thedestr. 2, 22767 Hamburg
> >
> > Mobil +49 (0)1577 170 73 84
> > Tel +49 (0)40 439 10 68-3
> > Fax +49 (0)40 439 10 68-5
> >
> > http://www.testkreis.de
> > Beratung, Tests und Schulungen für barrierefreie Websites
> >
> > Jonathan Avila schrieb am 06.08.2015 16:30:
> >
> >> Detlev, perhaps aria-hidden is not being updated in time for the screen
> >> reader
> >> to see the updated content.
> >>
> >> Jonathan
> >>
> >> --
> >> Jonathan Avila
> >> Chief Accessibility Officer
> >> SSB BART Group
> >> = EMAIL ADDRESS REMOVED =
> >> Phone 703.637.8957
> >> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> >>
> >>
> >>

From: Léonie Watson
Date: Thu, Aug 06 2015 11:08AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ]
> On Behalf Of Birkir R. Gunnarsson
> Sent: 06 August 2015 17:26
> Be mindful of using aria-hidden="false" as it may override things inside the
> tabpanel that are supposed to be hidden.
> <div role="tabpanel" aria-hidden="false"> <div id="userOpinionSecret"
> style="display: none">WE know this user, he is not popular</div> </div>
> Users, at least of some screen readers, will see tthis text, because aria-
> hidden="false" overrides display: none; If you are using display: none type
> class to hide inactive tabpanels you do not need to add aria-hidden to that.

One way to keep these two things working together, and to ensure accessibility is not overlooked when the widget is updated in the future, is to use CSS attribute selectors to hook the visual display into the state of the ARIA.

So when aria-hidden="true", display:none; will always be set, and vice versa. This technique is used on this disclosure widget example:
http://ljwatson.github.io/design-patterns/disclosure-button1/disclosure.html

The CSS for this (in the above example) looks like this:

div[aria-hidden="true"]
{
display: none;
}

div[aria-hidden="false"]
{
display: block;
border: 1px #000 solid;
padding: 1em;
background: #555;
color: #FFF;
}

Léonie.

From: Joseph Sherman
Date: Thu, Aug 06 2015 11:19AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Also for keyboard-only users without AT wouldn't it be hard to know when to use arrow navigation in tabs?


Joseph

From: Bryan Garaventa
Date: Thu, Aug 06 2015 12:21PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

> Also for keyboard-only users without AT wouldn't it be hard to know when to use arrow navigation in tabs?

Not if the widget is programmed intuitively.

E.G If the tabs flow from left to right in a single row, it would be a simple matter to use a CSS pseudo element such as :after to append left/right pointing arrows to clue the sighted keyboard user into this functionality.

From: Steve Faulkner
Date: Thu, Aug 06 2015 12:29PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Hi Birkir,

I tested and found same, which is troubling as the implementation
definition does not reflect this behaviour.
Will file a bug.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 6 August 2015 at 17:49, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED =
> wrote:

> This has been the case in iOS/Voiceover (last tested on iOS8.2 on
> iPhone/iPad).
> I can throw together an example and retest, we have had a few upgrades.
>
>
>
> On 8/6/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> > On 6 August 2015 at 17:25, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED =
> >> wrote:
> >
> >> <div role="tabpanel" aria-hidden="false">
> >> <div id="userOpinionSecret" style="display: none">WE know this user,
> >> he is not popular</div>
> >> </div>
> >>
> >
> > can you provide examples of AT/browser combinations where this is
> announced
> > by AT?
> >
> > --
> >
> > Regards
> >
> > SteveF
> > Current Standards Work @W3C
> > <
> http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: _mallory
Date: Thu, Aug 06 2015 12:54PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Little pictures of arrows do not change the years of training by
every website that you tab from focusable to focusable.

Users discover arrows by tabbing and shift-tabbing around several
times before then giving Plan B (the arrows) a try. This may or
may not be after trying various combinations of ctrl, alt, and
shift.

This will hopefully go away as more sites start using arrows for
tabs.

_mallory

On Thu, Aug 06, 2015 at 11:21:16AM -0700, Bryan Garaventa wrote:
> > Also for keyboard-only users without AT wouldn't it be hard to know when to use arrow navigation in tabs?
>
> Not if the widget is programmed intuitively.
>
> E.G If the tabs flow from left to right in a single row, it would be a simple matter to use a CSS pseudo element such as :after to append left/right pointing arrows to clue the sighted keyboard user into this functionality.
>
>
>

From: Jonathan Avila
Date: Thu, Aug 06 2015 1:24PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

> Little pictures of arrows do not change the years of training by every website that you tab from focusable to focusable.

I agree and I think arrows would be confusing and would clutter the control.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Bryan Garaventa
Date: Thu, Aug 06 2015 2:07PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

It depends on the paradigm and the UI obviously, menu buttons already typically have downward pointing arrows to indicate this functionality for example.

The point is, as long as ARIA widgets are not programmed consistently, they will never be understood properly.

From: Birkir R. Gunnarsson
Date: Thu, Aug 06 2015 2:18PM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | Next message →

Leonie
I was referring to a situation where aria-hidden="false" is used on
visble tabpanel (and that makes sense), but the tabpanel itself
contains content that is hidden, either because it is infor for
developers, or because the tabpanel contains expandable sections or
error messages.
I saw this in two different scenarios:
1. Developers used hidden inputs to store system data
<input type="hidden" value="some value">
They were reported by Voiceover on iOS as form fields with no label.
The other situation was tabpanel containing a form, the error messages
were present but hidden with display: none.
Voiceover on iOS would read these error messages as you swipe through
the tabpanel.
The minute I removed aria-hidden="false" everything worked as expected.
As for keyboard operations.
Yes, consistent implementations should be used wherever possible.
I see cases for tabkey being allowed alongside or even instead of
arrow keys for tab navigation, especially when you only have 2 tabs.
But without consistency we cannot teach users to work with our
widgets, so that is why I always refer people first to the ARIA APG
recommendations for the pattern and tell them that , while APG is not
normative, they should take note of the proposed keyboard
functionality for the widget and implement it unless they have
specific reasons not to.



On 8/6/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> It depends on the paradigm and the UI obviously, menu buttons already
> typically have downward pointing arrows to indicate this functionality for
> example.
>
> The point is, as long as ARIA widgets are not programmed consistently, they
> will never be understood properly.
>
>

From: Steve Faulkner
Date: Tue, Aug 11 2015 1:32AM
Subject: Re: tabpanel mark-up, possible effect of role=presentation
← Previous message | No next message

hi Birkir, this is a bug in webkit that has been fixed
https://lists.w3.org/Archives/Public/public-pfwg/2015Aug/0024.html

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 6 August 2015 at 17:49, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED =
> wrote:

> This has been the case in iOS/Voiceover (last tested on iOS8.2 on
> iPhone/iPad).
> I can throw together an example and retest, we have had a few upgrades.
>
>
>
> On 8/6/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> > On 6 August 2015 at 17:25, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED =
> >> wrote:
> >
> >> <div role="tabpanel" aria-hidden="false">
> >> <div id="userOpinionSecret" style="display: none">WE know this user,
> >> he is not popular</div>
> >> </div>
> >>
> >
> > can you provide examples of AT/browser combinations where this is
> announced
> > by AT?
> >
> > --
> >
> > Regards
> >
> > SteveF
> > Current Standards Work @W3C
> > <
> http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >