Primary tabs could not work in certain situations due to a wrong ARIA role [#1932948]

Comment	File	Size	Author
#8	fix_primary_tabs.patch	442 bytes	falcon03

Comment #1

falcon03 CreditAttribution: falcon03 commented 4 March 2013 at 12:14

Issue tags:

+JavaScript, +Usability, +Accessibility

tagging

Log in or register to post comments

Comment #2

andrewmacpherson CreditAttribution: andrewmacpherson commented 4 March 2013 at 21:18

I don't currently have access to a Mac, so wasn't able to test this on OS X.

I tested with the following set-ups, and didn't encounter a problem:

Windows 7, Firefox 13, NVDA 2011.3
Windows 7, Chrome 23, ChromeVox 1.25

Primary tabs were announced as links within list items, and were operable (both with and without the overlay).

Anyone else able to confirm this on OS X?

Log in or register to post comments

Comment #3

danielnolde CreditAttribution: danielnolde commented 9 March 2013 at 13:13

I can confirm #2 that primary- as well as sub-tabs are working as expected in graphical browsers Chrome 25, Safari 6.0.1 and Firefox 15.0.1 under Mac OS X 10.8.2 (tested on admin/content/comment logged in as admin).

Log in or register to post comments

Comment #4

danielnolde CreditAttribution: danielnolde commented 9 March 2013 at 13:13

I can confirm #2 that primary- as well as sub-tabs are working as expected in graphical browsers Chrome 25, Safari 6.0.1 and Firefox 15.0.1 under Mac OS X 10.8.2 (tested on admin/content/comment logged in as admin).

Log in or register to post comments

Comment #5

mgifford

he/him

English

CreditAttribution: mgifford commented 28 March 2013 at 20:36

Is this possibly a VoiceOver issue? So far it doesn't seem like anyone has been able to reproduce this. That happens easily enough.

Log in or register to post comments

Comment #6

falcon03 CreditAttribution: falcon03 commented 1 April 2013 at 12:00

@everyone: primary tabs at admin/content work great for me now. But tabs at
/admin/config/people/accounts
and at
/admin/modules
do not.

I do not have a windows testing environment right now, unfortunately.

Log in or register to post comments

Comment #7

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 15 April 2013 at 03:55

Status:

Active

» Postponed (maintainer needs more info)

Sounds like we need a bit more information to reproduce this bug.

Log in or register to post comments

Comment #8

falcon03 CreditAttribution: falcon03 commented 30 May 2013 at 13:57

Title:	Primary tabs do not work when overlay module is disabled	» Primary tabs could not work in certain situations due to a wrong ARIA role
Status:	Postponed (maintainer needs more info)	» Needs review

File	Size
fix_primary_tabs.patch	442 bytes

@webchick: I found what was causing the problem. In seven' page.html.twig (but not in other themes or in the core template), the variable to output primary tabs was wrapped in a div which the ARIA role "tab" was assigned to. Since the "tab" ARIA role shouldn't have been used this way, Voiceover was going crazy and wasn't intercepting the primary tabs correctly. I'm attaching a patch to fix the problem.

On a side note, though, can someone tell me why tabs in seven' page.html.twig are printed from a variable called "primary_local_tasks" while elsewhere they are printed from a variable called "tabs"? This seems not consistent to me...

Also, the default page.html.twig could need some cleanup, I think; essentially it could need just some new lines to make the code more readable at a quick glance (for sighted user) and tidier (for anyone). Maybe it's a different issue, though.