WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Role Application issue

for

From: Nikhil Mittal
Date: Jun 25, 2018 4:44AM

The demo of the url can be seen in following youtube video -
https://www.youtube.com/watch?v=MVwu237E1qA.


On Mon, Jun 25, 2018 at 11:54 AM 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
>


--
Thanks & Regards
Nikhil Mittal