WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Role Application issue

for

From: Brandon Keith Biggs
Date: Jun 25, 2018 5:49AM

Hello,
The only widget that you would need to allow the user to be in brows mode
is the Internet Explorer application.
I would pop them out of the edit mode and allow them to navigate as if they
were really in a web page. That is going to be the most difficult of all
the widgets because most of the keys have been taken by the web browser
already.
I would make sure you have at least one screen reader UX person working
with you on this.
Thanks,



Brandon Keith Biggs <http://brandonkeithbiggs.com/>;

On Sun, Jun 24, 2018 at 11:24 PM, Nikhil Mittal < <EMAIL REMOVED> >
wrote:

> Hi,
>
> We have various components in our widget area. Some of the *few* are listed
> below
> 1. Desktop
> 2. File Explorer
> 3. Control Panel/ Settings
> 4. MS Office (Applications - Excel, Powerpoint, Access, word, Outlook)
> 5. Internet Explorer
> 6. Start Menu
> 7. Task bar
> and others.
> Its kind of a personal machine inside a web browser.
> Office component will support everything including panes, dialog boxes,
> file menu *every *feature that office supports.
>
> We have provided role application because inside app Area we have our own
> keyboard shortcut to interact with the application.
>
> Also when page is loaded then depending on the parameters provided above
> widgets are loaded. There are more then 7000 scenarios for this.
>
> So it is not possible to actually find which will be the focused element
> when page is loaded. Also sometimes inner component loses focus by calling
> blur and then track key down on body for keyboard handling. So even if we
> track the first focused element how can we capture the keys when focus is
> moved in between to body by a inner component. Also considering the
> complexity and vast code of widgets and components it is not possible to do
> any change related to this in components. So looking for a common solution.
>
> Regards
> Nikhil Mittal
>
> On Sun, Jun 24, 2018 at 2:23 AM Birkir R. Gunnarsson <
> <EMAIL REMOVED> > wrote:
>
> > 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.
> > > > > > > > > >
>
>
> --
> Thanks & Regards
> Nikhil Mittal
> > > > >