E-mail List Archives
Re: Role Application issue
From: Birkir R. Gunnarsson
Date: Jun 23, 2018 2:53PM
- Next message: Edy kok: "Re: WebAIM-Forum Digest, Vol 159, Issue 23"
- Previous message: David Engebretson Jr: "Re: Accessible project manager"
- Next message in Thread: Nikhil Mittal: "Re: Role Application issue"
- Previous message in Thread: Brandon Keith Biggs: "Re: Role Application issue"
- View all messages in this Thread
The application role forces all screen readers into "application" or
"forms" mode. All key presses are routed through to the webpage. In
some screen readers it is not even possible to force browse mode with
focus inside an element with role="application".
Check out the role definition at:
http://www.w3.org/TR/wai-aria-1.1/#application
NOte in particular the situations in which the application role should be used.
1. Make sure no standard structure roles (listbox, grid, menus etc.)
match the patterns you want to implement.
2. Remember that non-focusable content inside an application role area
is not accessible to a screen reader user unless you associate it with
a focusable element or place it inside an element with role="document"
(even in that situation you may experience accessibility support
issues, better to put the interactive portion in an application role
than the static portion inside a document role).
So if your whole page is an interactive widget, e.g. a spreadsheet,
with no static text, or at least static text that is no more than 3 or
4 words and can be associated with a focusable element, you can use
the application role (note rold="grid" is more appropriate for a
spreadsheet).
So make sure you have no other options, use the application role on
the smallest part of the page possible. Good luck.
On 6/22/18, Brandon Keith Biggs < <EMAIL REMOVED> > wrote:
> Hello,
> From what I understand is you want one area that allows the user to be in
> brows mode and another area that requires the user to be in edit mode.
> This is OK, but if you are making something like a word processor, there
> are only two widgets, the menu and the edit area. You can add other panes,
> but that's pretty unusual.
> Can you please explain why your design does not fit into the menu and edit
> field widgets? Thousands of options sounds like a very extensive menu to
> me.
> Thanks,
>
> Brandon Keith Biggs <http://brandonkeithbiggs.com/>
>
>
> On Fri, Jun 22, 2018 at 12:14 AM Nikhil Mittal < <EMAIL REMOVED> >
> wrote:
>
>> The widget in appArea is itself an application.
>> It is similar to desktop application like microsoft office/ Paint and
>> other
>> desktop applications(number of interactive elements in that area ~1000)
>> These application change based on the scenario and having a fixed focused
>> element is not possible.
>>
>> Also pressing enter as you specified in first option is not a solution as
>> we want to pass every key from body to application unless user press some
>> key in navigation area.
>>
>>
>> On Thu, Jun 21, 2018 at 7:28 PM Brandon Keith Biggs <
>> <EMAIL REMOVED> > wrote:
>>
>> > Hello,
>> > There are two ways to interact with role="application".
>> > 1. Hit enter on the application element and use the application as if
>> > it
>> is
>> > another web page. You can put other elements there and the screen
>> > reader
>> > will move through those elements in brows mode.
>> > 2. Hit enter on the application and pop the screen reader into edit
>> > mode
>> > where all keys are passed to the edit widget inside the application.
>> >
>> > You currently have 1, but it sounds as if you want 2. 2 is highly
>> > discouraged unless you have a screen reader user testing UX or building
>> > your app. Number 2 is mostly for games and is considered the "canvas"
>> > element for screen readers.
>> > You do the second by doing the following:
>> >
>> > <div role="application">
>> > <input type="button" autoFocus="true" value="Click me" />
>> > <p aria-live="polite" id="spk"></p>
>> > </div>
>> >
>> > The spk element is to send messages to the screen reader which you need
>> to
>> > do in this Window, Icon, Menu, Message (WIMM) interface. Remember that
>> > in
>> > this mode, you need to program everything and users get upset if
>> > expectations are not met.
>> >
>> > You said you are making a word processor. This last option (number 2),
>> > is
>> > NOT what you do to make a word processor. As a screen reader user, I
>> > have
>> > expectations and workflows for Word processors. You can't get that
>> > functionality with programming it manually.
>> > Instead, use the existing edit fields HTML provides for this reason,
>> > such
>> > as:
>> >
>> >
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20Standard%20Edits%20With%20Right%20Click/demo.htm
>> >
>> > Please let me know if there is some reason why you would not want to
>> > use
>> > the above widget.
>> > Thank you,
>> >
>> >
>> >
>> > Brandon Keith Biggs <http://brandonkeithbiggs.com/>
>> >
>> >
>> > On Thu, Jun 21, 2018 at 5:55 AM Nikhil Mittal
>> > < <EMAIL REMOVED>
>> >
>> > wrote:
>> >
>> > > Hello All,
>> > >
>> > > We are facing issue regarding accessibility for role="application".
>> > >
>> > > We have 2 widgets one is a complex widget for which we need to
>> > > provide
>> > role
>> > > application as widget has its own complex keyboard handling and
>> > > another
>> > is
>> > > navigator(similar to toolbar)
>> > >
>> > > Now when body has the focus and user press down arrow the complex
>> widget
>> > is
>> > > skipped and arrow keys goes to the navigator.
>> > >
>> > > The HTML is something similar to as specified below.
>> > >
>> > > <body> <div class="appArea" role="application"> .......//Complex
>> widgets
>> > > </div> <div class="toolbar"> ......//Buttons, dropdowns </div>
>> > > </body>
>> > > Our complex widget is designed in such a way that it captures keys on
>> > body
>> > > and consumes it. So as per our requirement if focus is on body the
>> keys
>> > > should reach our complex widget.
>> > >
>> > > Providing role application on body revokes us the default
>> > > functionality
>> > > that is provided by screen reader for dialogs and toolbar.
>> > >
>> > > I have created a dummy implementation of our application at
>> > > https://roleapplication.herokuapp.com/index.html
>> > >
>> > > Also same question has been posted at following stackoverflow link in
>> > case
>> > > more details are required -
>> > >
>> >
>> https://stackoverflow.com/questions/50798108/accessibility-role-application
>> > >
>> > > Any help will be appreciated as we have spent days tackling this
>> probelm.
>> > >
>> > > --
>> > > Thanks & Regards
>> > > Nikhil Mittal
>> > > >> > > >> > > >> > > >> > >
>> > >> > >> > >> > >> >
>>
>>
>> --
>> Thanks & Regards
>> Nikhil Mittal
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
- Next message: Edy kok: "Re: WebAIM-Forum Digest, Vol 159, Issue 23"
- Previous message: David Engebretson Jr: "Re: Accessible project manager"
- Next message in Thread: Nikhil Mittal: "Re: Role Application issue"
- Previous message in Thread: Brandon Keith Biggs: "Re: Role Application issue"
- View all messages in this Thread