WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Role Application issue

for

From: Brandon Keith Biggs
Date: Jun 26, 2018 7:49AM

Hello,
Yes:
<div role="application">
<input type="button" autoFocus="true" value="Press slash to hear
instructions" />
</div>

It is incredibly difficult to add accessibility after something has been
developed, so I really wish you luck. I compare it to adding chocolate
chips to cookies after they have come out of the oven.
You should make sure you have a screen reader, either Voice Over on Mack,
Orca on Linux, or NVDA on Windows. They are all free.
NVDA has a speech viewer in the tools menu that visually shows what is
being said, so you can better test. But you should really get some screen
reader users to comment on what you are doing before you get too far.
Thanks,


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

On Mon, Jun 25, 2018 at 10:57 PM, Nikhil Mittal < <EMAIL REMOVED> >
wrote:

> Hello,
>
> Please have a look at our product in following youtube video -
> https://www.youtube.com/watch?v=MVwu237E1qA.
>
> We cant rewrite our project as it is already developed. As we are
> simulating users machine so we dont have much option in terms of UX and UI.
>
> Also as replied by you(Brandon) on stackoverflow the information about
> enter key that by pressing it we will enter into the application mode. We
> have similar requirement but need to do it by code whenever focus comes on
> the body. Is there any way we can do this.
>
>
>
>
> On Mon, Jun 25, 2018 at 5:19 PM Brandon Keith Biggs <
> <EMAIL REMOVED> > wrote:
>
> > 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
> > > > > > > > > > > > > > >
> > > > > > > > > >
>
>
> --
> Thanks & Regards
> Nikhil Mittal
> > > > >