- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 5 Nov 2014 13:19:41 -0600
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: Jason Kiss <jason@accessibleculture.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, PFWG <w3c-wai-pf@w3.org>
- Message-ID: <OF41788D56.DD5DFB6A-ON86257D87.006A0A83-86257D87.006A2C6D@us.ibm.com>
The lines are getting blurred Alex. SVG now supports an IFrame and a Canvas element. I think we will need @inert in the very near future. I would prefer the browser handle it but if you see my last post that will not always happen. Rich Schwerdtfeger From: Alexander Surkov <surkov.alexander@gmail.com> To: Richard Schwerdtfeger/Austin/IBM@IBMUS Cc: Jason Kiss <jason@accessibleculture.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, PFWG <w3c-wai-pf@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org> Date: 10/17/2014 10:42 AM Subject: Re: @inert and @aria-inert for disambiguating modal states Of course I don't think that SVG has to copy all HTML features, afaik SVG can be combined with HTML markup at some level so HTML @inert could do a job for SVG too. On the other hand if SVG needs some feature then I'd say it's worth to add it. After all ARIA is just about semantics for assistive technology while @inert is about UI. On Fri, Oct 17, 2014 at 9:24 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: ARIA does not just apply to HTML. It also applies to SVG and MANY elements formerly limited to HTML are now showing up in SVG. While I agree with you to a point Alex we need to think beyond just the HTML host language. Are you proposing that every host language duplicate all HTML features? ... just asking. I am copying the public pfwg list. Rich Rich Schwerdtfeger Inactive hide details for Alexander Surkov ---10/16/2014 08:04:51 AM---Hi, Jason. In general ARIA shouldn't duplicate every sinAlexander Surkov ---10/16/2014 08:04:51 AM---Hi, Jason. In general ARIA shouldn't duplicate every single HTML piece otherwise we From: Alexander Surkov <surkov.alexander@gmail.com> To: Jason Kiss <jason@accessibleculture.org> Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, PFWG < w3c-wai-pf@w3.org> Date: 10/16/2014 08:04 AM Subject: Re: @inert and @aria-inert for disambiguating modal states Hi, Jason. In general ARIA shouldn't duplicate every single HTML piece otherwise we get into the word where HTML serves presentational needs while ARIA servers for semantics. In this particular case it means I prefer to have HTML5 @inert attribute over @aria-inert. You referred to [1] which claims that @inert was removed because it's not supposed to be used in no context of HTML5 dialog element. I don't have any contrary instance so that rationale looks reasonable with me. Getting back to ARIA, it provides role="dialog" however it doesn't have a way to specify the dialog modality. @aria-inert could be used for that but that doesn't look like a nice approach, it also makes ARIA markup farther from HTML. I think I would prefer if role="dialog" carried some extra attribute for modality stuff. In short I'm up to @inert attribute if it has use case. I don't think I see a good reason why ARIA would need @aria-inert. Thanks. Alexander. [1] https://html5.org/r/8536 On Tue, Sep 30, 2014 at 9:08 PM, Jason Kiss <jason@accessibleculture.org> wrote: The PFWG is seeking feedback from the HTML Accessibility Task Force on the appropriate accessibility API mapping for an @aria-inert attribute for inert subtrees, and to reconsider the potential of the HTML "inert" attribute. The PFWG recently discussed a possible ARIA property, "aria-inert", to help disambiguate modal states, for example to programmatically establish that the underlying content "behind" a modal dialog is inert and cannot be interacted with, even if it is visible [1]. The group was considering how such an attribute would map to accessibility APIs, and it was noted that HTML used to include an "inert" attribute, but it was removed [2]. It's noted that there remains a section on "inert subtrees" in both the HTML5 PR [3] and the HTML5.1 nightly [4]. The general consensus in the group is that HTML's @inert was somewhere in between @aria-disabled and @aria-hidden. Mapping to @aria-disabled is not appropriate because @aria-disabled applies to the current element and focusable descendant elements only, not all descendant elements. Mapping to @aria-hidden, which, depending on the browser implementation, effectively removes the content from the accessibility tree, supports a semi-modal behavior of dialogs and menus, but is not quite correct because the underlying content "behind" the dialog or menu is actually rendered and visible, and this may have implications for some assistive technology like screen magnifiers. Other use cases for @inert or @aria-inert include carousels where you interact with one pane at a time but you can still see these other panes even though they're not active. Even if those inactive panes were marked up using @aria-hidden, there would still need to be a way to handle the focusability. Pop-up menus present another use case where sometimes the background might be inert, depending on the platform. Without @inert, and were @aria-inert to exist, it could have backwards-compatibility so that elements with both aria-hidden="true" and aria-inert="true" would be exposed as "inert, but not actually hidden." An author could use both to ensure the modal state worked in browsers that supported @aria-inert, and older browsers that only supported @aria-hidden. Members of the PFWG will chime in if I've misrepresented any aspect of their discussion on this question. Jason [1] http://www.w3.org/2014/06/23-aria-minutes.html#item01 [2] https://html5.org/r/8536 [3] http://www.w3.org/TR/html5/editing.html#inert-subtrees [4] http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees
Attachments
- image/gif attachment: graycol.gif
Received on Wednesday, 5 November 2014 19:20:16 UTC