Re: role=toolbar should become landmark role in ARIA 1.1

Toolbars for me are buttons that have an effect on the current page, or something on the current page. So I'm thinking text processing, crm like applications, applications in general. 

Social media buttons (even when grouped) are not toolbars in my opinion. 

—Michiel

> On 01 Jul 2015, at 15:22, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> I am neutral on it, slightly towards it being a good idea.
> We need to make sure not to map too many things as landmarks, else
> pages become "unlandmarkable" (when pages contain 20 or 30 or 50
> landmarks their usefulness as navigation aids evaporates).
> Given that pages generally don´t contain too many toolbars this might
> be all right.
> The risk is when toolbars are used (correctly I would say) to group
> together commonly used functions that appear multiple times on a page
> )such as a social sharing toolbar that appears next to each news story
> preview for instance).
> I also see this problem with the article tag mapping to role-'article'.
> I would propose that, like the tradition with region, toolbars are
> only mapped as landmarks if they have an explicit name assigned via
> aria-label (though it is actually a requirement in the spec if page
> contains more than one toolbar).
> -Birkir
> 
>> On 7/1/15, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:
>> All,
>> 
>> I'd like to hear opinions on the subject of this post.
>> 
>> We often encounter the situation that toolbars in business applications
>> running in the web are stuffed with functions (10+ buttons, combos etc.)
>> 
>> For ease of access, it would be desirable to use landmark navigation
>> features built in in user agents and assistive technology to directly
>> navigate to the toolbars.
>> 
>> The classy approach is to "wrap" a div with role toolbar in another div with
>> e.g. role=region labelled for instance "tools" and then to proceed
>> navigation to the inner content.
>> But this "costs" an additional parent DOM node and is therefore often
>> subject of discussion with Web UI performance groups wanting the leanest DOM
>> possible.
>> 
>> Another proposal is to provide access keys to buttons inside using the
>> (buggy) access key mechanism or even to provide custom JS for keyboard
>> navigation.
>> 
>> Having role=toolbar as a landmark role in ARIA 1.1 would avoid wrapping and
>> ease navigation to functions without additional effort from authoring side.
>> 
>> Thoughts?
>> 
>> Best Regards
>> Stefan
>> 
>> 
>> Dr. Stefan Schnabel
>> Senior User Experience Design Specialist
>> P&I Customer Innovation & Services
>> ASCOT - Standards Excellence
>> 
>> SAP SE | Dietmar-Hopp-Allee 16 | 69190 Walldorf, Germany
>> T: +49 (6227) 7-65652 F: +49 (6227) 78-29877
>> mailto:stefan.schnabel@sap.com W: www.sap.com<http://www.sap.com/>
>> 
>> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
>> Vorstand/SAP Executive Board: Bill McDermott
>> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board:
>> Hasso Plattner
>> Registergericht/Commercial Register Mannheim No HRB 350269
>> 
>> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
>> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
>> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
>> Vielen Dank.
>> 
>> This e-mail may contain trade secrets or privileged, undisclosed, or
>> otherwise confidential information. If you have received this e-mail in
>> error, you are hereby notified that any review, copying, or distribution of
>> it is strictly prohibited. Please inform us immediately and destroy the
>> original transmittal. Thank you for your cooperation.
>> 
>> Please consider the impact on the environment before printing this e-mail.
>

Received on Wednesday, 1 July 2015 14:09:51 UTC