18245 2012-07-18 17:49:09 +0000 Conveying state of an Active tab in tabbed panels to Assistive Technologies like screen readers 2016-04-14 14:20:01 +0000 1 1 1 Unclassified HTML WG HTML a11y Task Force unspecified Other other RESOLVED MOVED https://www.w3.org/Bugs/Public/show_bug.cgi?id=19159 http://www.whatwg.org/specs/web-apps/current-work/#the-nav-element a11y P3 normal --- 1 contributor robin bhawkeslewis chaals cobaco devarshipant eoconnor faulkner.steve hans.hillen lwatson mike mjs plh public-html-a11y public-html-admin public-html-wg-issue-tracking robin dave.null oldest_to_newest 70956 0 contributor 2012-07-18 17:49:09 +0000 This was was cloned from bug 17114 as part of operation convergence. Originally filed: 2012-05-19 00:00:00 +0000 ================================================================================ #0 contributor@whatwg.org 2012-05-19 00:00:21 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html Multipage: http://www.whatwg.org/C#the-nav-element Complete: http://www.whatwg.org/c#the-nav-element Comment: With the prevalence of tabbed navigation in newer websites, it would be nice to have a block element called "tab" to be used in the nav block element. Thank you. Posted from: 173.245.64.56 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 ================================================================================ #1 Devarshi Pant 2012-06-12 20:19:38 +0000 -------------------------------------------------------------------------------- When an active tabbed panel is made visually discernable using a different background color, it's equivalent is not available to screen reader users -- Can this info on active tab be passed on to screen readers using html5? Thanks, Devarshi (In reply to comment #0) > Specification: > http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html > Multipage: http://www.whatwg.org/C#the-nav-element > Complete: http://www.whatwg.org/c#the-nav-element > Comment: > With the prevalence of tabbed navigation in newer websites, it would be nice > to have a block element called "tab" to be used in the nav block element. > Thank you. > Posted from: 173.245.64.56 > User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 > Firefox/12.0 ================================================================================ 73788 1 robin 2012-09-13 15:47:51 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Rationale: Tabs are a presentational effect that can (and in a number of cases is) be done in such a way as to be AT friendly. If standardised this could be better handled through CSS. 73802 2 devarshipant 2012-09-13 18:38:47 +0000 (In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the Editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the Tracker Issue; or you may create a Tracker Issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > Status: Rejected > Rationale: Tabs are a presentational effect that can (and in a number of cases > is) be done in such a way as to be AT friendly. If standardised this could be > better handled through CSS. I do not understand your rationale and basis for rejection. The intent is to create a semantic equivalent of this presentational effect and its state (e.g., active) that you refer to. Please clarify why it cannot be done. 73803 3 faulkner.steve 2012-09-13 18:57:21 +0000 (In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the Editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the Tracker Issue; or you may create a Tracker Issue > yourself, if you are able to do so. For more details, see this document: > > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Rationale: Tabs are a presentational effect that can (and in a number of cases > is) be done in such a way as to be AT friendly. If standardised this could be > better handled through CSS. Hi Robin, claiming it is a presentational effect appears to be at odds with every accessibility API which provide distinct roles to identify the semantic structures of tabs [1](tab, tablist, tabpanels) which are implemented across OS's and platforms. They are provided because almost all UI languages have tab widgets. tabs are not merely presentational they are UI controls and have a role and states and properties that cannot be handled by CSS. [1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role 73804 4 faulkner.steve 2012-09-13 18:58:17 +0000 (In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the Editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the Tracker Issue; or you may create a Tracker Issue > yourself, if you are able to do so. For more details, see this document: > > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Rationale: Tabs are a presentational effect that can (and in a number of cases > is) be done in such a way as to be AT friendly. If standardised this could be > better handled through CSS. Hi Robin, claiming it is a presentational effect appears to be at odds with every accessibility API which provide distinct roles to identify the semantic structures of tabs [1](tab, tablist, tabpanels) which are implemented across OS's and platforms. They are provided because almost all UI languages have tab widgets. tabs are not merely presentational they are UI controls and have a role and states and properties that cannot be handled by CSS. [1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role 73805 5 bhawkeslewis 2012-09-13 19:18:54 +0000 For a CSS approach see: http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html 73807 6 faulkner.steve 2012-09-13 19:33:58 +0000 (In reply to comment #5) > For a CSS approach see: > > http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html doesn't ppaear to provide any info about how the semantics/states and properties of the tabs are to be conveyed or am I missing something? 73808 7 bhawkeslewis 2012-09-13 19:47:23 +0000 (In reply to comment #6) > (In reply to comment #5) > > For a CSS approach see: > > > > http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html > > doesn't ppaear to provide any info about how the semantics/states and > properties of the tabs are to be conveyed or am I missing something? Don't think you are. It's just an example of what a tabbing mechanism might look like in CSS. If this was added, mappings to accessibility API roles, states, and properties would have to be derived. If we also added markup for tab views that could use the CSS mechanism. Not sure of the merits of tab views being expressed as part of the structure of the document/application rather than presentation. 73809 8 jcraig 2012-09-13 19:59:56 +0000 Steve's concern is that semantics are needed for the controlling elements (e.g. tabs and tablist) versus the controlled elements (e.g. tabpanel). While I don't agree with Robin's statement that tabs are a presentational effect, the semantics mentioned in the CSS card-stack example are for the content sections (similar to ARIA's tabpanel role or a generic hidden/shown div) and may therefore only need to be marked as shown or hidden in the accessibility APIs rather than to have semantic roles or properties applied. Perhaps the confusion is that Robin should have said "card-stacks" rather than "tabs" are a presentational effect that can be used for semantic controls like tab panels, but in cases where the controlling elements indicate some additional functionality, it's the page authors responsibility to convey semantics through use of appropriate HTML elements or ARIA roles. 73826 9 mjs 2012-09-14 04:12:29 +0000 <with chair hat off> I personally disagree that tabs are purely presentational. While a set of panels where you show one at a time is a generic idea that could in principle be done with @hidden or with pure CSS, the tab strip and its relation to the set of views is clearly semantic, at least as much as a push button. <with chair hat on> Given where we are in the process with HTML5, and given that this is a new feature request, I recommend deferring this request to a future version of HTML. 73855 10 faulkner.steve 2012-09-14 09:28:29 +0000 (In reply to comment #9) > <with chair hat off> > I personally disagree that tabs are purely presentational. While a set of > panels where you show one at a time is a generic idea that could in principle > be done with @hidden or with pure CSS, the tab strip and its relation to the > set of views is clearly semantic, at least as much as a push button. > > <with chair hat on> > Given where we are in the process with HTML5, and given that this is a new > feature request, I recommend deferring this request to a future version of > HTML. Hi Maciej, I was acting under the assumption that this was something being disucussed for html.next. Would be good if we could define a keyword that flags bugs for html.next. I realise we have a sperate product for it, but if bugs get filed or re-opened against the html spec then it would be helpful to be able to flag as html.next rather having to refile. note this issue has been previously raised: http://www.w3.org/html/wg/tracker/issues/134 and marked as postponed. 73926 11 mjs 2012-09-14 13:25:26 +0000 (In reply to comment #10) > > I was acting under the assumption that this was something being disucussed for > html.next. Would be good if we could define a keyword that flags bugs for > html.next. I realise we have a sperate product for it, but if bugs get filed or > re-opened against the html spec then it would be helpful to be able to flag as > html.next rather having to refile. > > note this issue has been previously raised: > http://www.w3.org/html/wg/tracker/issues/134 and marked as postponed. You can just change the product to HTML.next. You can even do that right when reopening. 73935 12 devarshipant 2012-09-14 17:35:14 +0000 > You can just change the product to HTML.next. You can even do that right when > reopening. It is already categorized as HTML.next. 81723 13 robin 2013-01-21 15:59:29 +0000 Mass move to "HTML WG" 81841 14 robin 2013-01-21 16:02:14 +0000 Mass move to "HTML WG" 84179 15 cobaco 2013-03-09 15:29:34 +0000 there's actually no css/html additons needed for that: You can already do it by adding a (visually hidden) <input type="radio" aria-controls="tabpanelid"> to store the tabstate (along with the appriate role attributes) An example page showing this approach can be found at http://freemen.be/examples/tabs_example.html Tested to work in the current incarnation of all 4 major browsers. 84223 16 devarshipant 2013-03-11 15:02:35 +0000 A form field list (Ins + F5 in JAWS 13 / IE8 / Win 7) shows radio button controls as 'Tab 1 Tab' 'Tab 2 Tab' etc. A radio button control list (Ins + Ctrl + r) gives a list of radio buttons as 'Tab 1 radio button checked' 'Tab 2 radio button not checked' etc. Where is the semantic equivalent for the active tab, unless the key word here is 'radio button checked'? -Devarshi (In reply to comment #15) > there's actually no css/html additons needed for that: You can already do > it by adding a (visually hidden) <input type="radio" > aria-controls="tabpanelid"> to store the tabstate (along with the appriate > role attributes) An example page showing this approach can be found at > http://freemen.be/examples/tabs_example.html Tested to work in the current > incarnation of all 4 major browsers. 117426 17 lwatson 2015-01-22 13:56:42 +0000 This draft extension proposes a number of elements and attributes for implementing tabs and other similar constructs: http://bkardell.github.io/common-panel/ 125847 18 chaals 2016-04-14 14:20:01 +0000 In WICG: http://bkardell.github.io/common-panel/