E-mail List Archives
Thread: Role Application issue
Number of posts in this thread: 14 (In chronological order)
From: Nikhil Mittal
Date: Thu, Jun 21 2018 6:54AM
Subject: Role Application issue
No previous message | Next message →
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
From: Brandon Keith Biggs
Date: Thu, Jun 21 2018 7:58AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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
> > > > >
From: Nikhil Mittal
Date: Fri, Jun 22 2018 1:14AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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
From: Brandon Keith Biggs
Date: Fri, Jun 22 2018 9:42AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >
From: Birkir R. Gunnarsson
Date: Sat, Jun 23 2018 2:53PM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
From: Nikhil Mittal
Date: Mon, Jun 25 2018 12:24AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
From: Nikhil Mittal
Date: Mon, Jun 25 2018 4:44AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
From: Brandon Keith Biggs
Date: Mon, Jun 25 2018 5:43AM
Subject: Re: Role Application issue
← Previous message | Next message →
Hello,
You are going to need screen reader users to test this out, it sounds as if
you are trying to take on Google Drive.
What Google Drive does is keeps the screen reader user in edit mode, but
shifts the focus between different elements on the page.
It uses editable fields for writing text, aria menus for menus, grid for
spreadsheets, and dialogues for dialogues.
If I were you, I would reduce the amount of time needed to test and build
this by using AccDC:
https://github.com/WhatSock/accdc
AccDC is a library that has pretty much all the widgets you need in the
coding Arena. What you would do is combine the menu with the different
application widgets like the spreadsheet:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm
Note that the desktop on the PC is very badly designed for a screen reader
user, and it would be much better if you only had a linear menu rather than
a grid with random icons all around the screen.
Google drive allows people to switch between grid view and list view which
is something you should copy.
Google drive does not allow for first letter navigation which is something
they should allow.
They also don't allow for custom keymappings which is also a major downside
to GSuite products.
I would say build your product combining widgets from AccDC and then have
screen reader users test it. Otherwise, if you try and build your own
widgets, you would need a screen reader user to test every few updates to
the code to insure the UX is OK (just like you have sighted users looking
at how the display looks).
Thanks,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
On Sun, Jun 24, 2018 at 11:24 PM, Nikhil Mittal < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >
From: Brandon Keith Biggs
Date: Mon, Jun 25 2018 5:49AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >
From: Nikhil Mittal
Date: Mon, Jun 25 2018 11:57PM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
From: Tim Harshbarger
Date: Tue, Jun 26 2018 6:32AM
Subject: Re: [EXTERNAL] Role Application issue
← Previous message | Next message →
My personal opinion is that using role="application" might be ok in this situation. If I understand the situation correctly, it sounds like you are attempting to simulate the Windows desktop environment. If you use role="application" and mimic many of the keyboard shortcuts that are used in the actual environment, I think it might make the simulation possibly more accessible and useful to both to people who use the keyboard and people who use screen readers.
You likely will want to use native HTML controls and ARIA design patterns that best match what is used in the Windows environment to help with the simulation. However, there is likely at least some limitation to how closely the simulated environment can get to mimicking the actual environment.
If you do that, you may also want to provide some kind of help guide that explains what shortcut keys are available since you will likely only want to implement some of the keyboard shortcuts that are available in the actual environment rather than all the keyboard shortcuts that are available. Maybe even provide a link outside the role="application" that provides that information to users?
I hope that helps at least some.
From: Brandon Keith Biggs
Date: Tue, Jun 26 2018 7:49AM
Subject: Re: Role Application issue
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > >
From: Nikhil Mittal
Date: Fri, Jun 29 2018 6:30AM
Subject: Re: Role Application issue
← Previous message | Next message →
Thank you Brandon, Confirming we are testing with JAWS, NVDA and voiceover.
And yeah adding accessibility on already developed product is a nightmare
but no option available here.
For solution to the problem, a professional accessibility expert(Reinhard)
suggested to notify the user to switch to focus mode when uer moves to the
app area.
So even if the focus would be on body keys will be intercepted by our
application.
This way we will get the key and accessibility user will also know how to
use the application.
Regards
Nikhil Mittal
On Tue, Jun 26, 2018 at 7:20 PM Brandon Keith Biggs <
= EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > > > > > > >
> > > > >
--
Thanks & Regards
Nikhil Mittal
From: Nikhil Mittal
Date: Fri, Jun 29 2018 6:36AM
Subject: Re: [EXTERNAL]Role Application issue
← Previous message | No next message
Confirming, We have mimiced all Keyboard pathways available to normal
window user. In certain limited scenarios such as ALT+F4 user can use our
cirtual keyboard embedded in our application itself to perform the pathway.
Using native HTMl controls and Aria design patterns are not feasible in the
appArea as the app has already been developed and it would be difficult to
create the exact simulation.
For help documentation users are provided with book and instructor which
lists the keyboard pathways to interact with the simulation.
For solution to the problem provided by accessibility expert(Reinhard) , as
you also suggested we will notify the user to switch to focus mode when
user moves to the app area.
So even if the focus would be on body keys will be intercepted by our
application.
This way we will get the key and accessibility user will also know how to
use the application.
On Tue, Jun 26, 2018 at 6:03 PM Tim Harshbarger <
= EMAIL ADDRESS REMOVED = > wrote:
> My personal opinion is that using role="application" might be ok in this
> situation. If I understand the situation correctly, it sounds like you are
> attempting to simulate the Windows desktop environment. If you use
> role="application" and mimic many of the keyboard shortcuts that are used
> in the actual environment, I think it might make the simulation possibly
> more accessible and useful to both to people who use the keyboard and
> people who use screen readers.
> You likely will want to use native HTML controls and ARIA design patterns
> that best match what is used in the Windows environment to help with the
> simulation. However, there is likely at least some limitation to how
> closely the simulated environment can get to mimicking the actual
> environment.
>
> If you do that, you may also want to provide some kind of help guide that
> explains what shortcut keys are available since you will likely only want
> to implement some of the keyboard shortcuts that are available in the
> actual environment rather than all the keyboard shortcuts that are
> available. Maybe even provide a link outside the role="application" that
> provides that information to users?
>
> I hope that helps at least some.
>