WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Role Application issue

for

From: Nikhil Mittal
Date: Jun 22, 2018 1:14AM

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