WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Deque AXE plugin

for

From: Marcy Sutton
Date: Oct 26, 2018 12:10PM


The axe Chrome and Firefox plugins are not open source, and their license does not allow them to be modified. Please refer to the terms of use: https://www.deque.com/terms-of-use/axe-ext <https://www.deque.com/terms-of-use/axe-ext>

That said, we know many people desire a JSON export from the axe extension. That feature isn't currently available with the free axe plugins, but can be otherwise achieved with our open source axe-core and axe-cli tools, as well as the WorldSpace Attest Devtools extension.

Marcy Sutton | Developer Advocate
Deque Systems - Accessibility for Good
deque.com <http://deque.com/>;

> On Oct 26, 2018, at 11:00 AM, <EMAIL REMOVED> wrote:
>
> Send WebAIM-Forum mailing list submissions to
> <EMAIL REMOVED>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> <EMAIL REMOVED>
>
> You can reach the person managing the list at
> <EMAIL REMOVED>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Deque AXE plugin ( <EMAIL REMOVED> )
> 2. accessible combo boxes and correct behaviour
> ( <EMAIL REMOVED> )
> 3. Re: [EXTERNAL] Navigation in application mode (Isabel Holdsworth)
> 4. Re: keeping jaws focus on a link after page load
> (Isabel Holdsworth)
> 5. Re: Another table sort question (Isabel Holdsworth)
> 6. Re: Deque AXE plugin (Steve Faulkner)
> 7. Re: Keyboard accessible HTML5 video player (Sudheer Babu)
> 8. Accessible Tree Navigation? (Henry, Michael (IntelliDyne))
> 9. GitHub and the Colour Contrast Analyzer latest version
> (Karlen Communications)
> 10. Re: Accessible Tree Navigation? (Birkir R. Gunnarsson)
> 11. Re: Another table sort question (Birkir R. Gunnarsson)
> 12. Re: [EXTERNAL] Navigation in application mode (glen walker)
> 13. Re: Accessible Tree Navigation? (Henry, Michael (IntelliDyne))
>
> From: < <EMAIL REMOVED> >
> Subject: [WebAIM] Deque AXE plugin
> Date: October 25, 2018 at 11:43:51 PM PDT
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
>
>
> All,
>
>
>
> Does anyone know if you can get access to the source of AXE for Firefox and
> Chrome? As I would like to see if I could make a modification to the plugin.
> That is, to save the results to a JSON. Also with AXE Core API which you can
> include in your source. Is it possible to create this as a code which you
> insert into a page which is already loaded and you don't have direct access
> to the source?
>
>
>
>
>
> Sean
>
>
>
>
>
>
>
> From: < <EMAIL REMOVED> >
> Subject: [WebAIM] accessible combo boxes and correct behaviour
> Date: October 25, 2018 at 11:54:16 PM PDT
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
>
>
> All,
>
>
>
> I have seen many attempts of accessible combo boxes. What I have not seen
> and require verification. When a combo box is open and the keyboard user is
> navigating the list of options. If they press escape. The prior value should
> be maintained in the edit field and not overwritten with the currently
> selected value. All the combo boxes I have tested even the one from W3C ARIA
> 1.1. best practise does what I have described when using Firefox 62. I must
> admit I have not tested this with IE11 or Chrome.
>
>
>
>
>
> For example: A combo box with 3 options. The edit field is blank. The combo
> box is open by using the alt down arrow. The down arrow is moved to the 2nd
> value called "2". The user presses escape and the value 2 is inserted into
> the edit field rather than kept blank.
>
>
>
> I understand Chrome has decided to change how combo boxes are open now.
> Instead of using alt down arrow or the down arrow. The enter key is used. I
> believe this is in Chrome 70. Thoughts on this?
>
>
>
>
>
>
>
> From: Isabel Holdsworth < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Navigation in application mode
> Date: October 26, 2018 at 12:21:09 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> So if I wanted to interrogate an item within a grid using a
> screenreader, say for example to read a name or number character by
> character, how would I do that if the arrow keys are being passed to
> the application?
>
> On 22/06/2018, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
>> The
>> W3C spec never specifies exactly how a user agent should behave, but
>> strongly hints at it.
>> If NVDA does not switch into application mode inside a grid that's an
>> NVDA bug (unless the grid is marked as readonly).
>> This is why authors still use the application role on a grid, like we
>> did with the datepicker, but screen readers should address these
>> issues. I will go look at NVDA issues and file one if needed.
>>
>>
>>
>> On 6/22/18, glen walker < <EMAIL REMOVED> > wrote:
>>> Birkir, when you say that navigation to a grid should automatically
>>> switch
>>> to application/forms mode, are you saying a well-behaved screen reader
>>> should do that for you or that the web developer should be forcing it
>>> somehow?
>>>
>>> The spec for the grid role doesn't explicitly say a user agent should
>>> switch modes but it does say the author should manage the focus.
>>>
>>> When navigating to a grid, NVDA doesn't give an audible notification that
>>> forms mode switched but JAWS does. Using the right arrow after entering
>>> a
>>> grid, NVDA just reads character by character whereas JAWS will navigate
>>> to
>>> the next grid cell.
>>>
>>> So it sounds like JAWS handles the grid as you explained but NVDA does
>>> not.
>>>
>>>
>>>
>>>
>>> On Fri, Jun 22, 2018 at 11:50 AM, Birkir R. Gunnarsson <
>>> <EMAIL REMOVED> > wrote:
>>>
>>>> I would go with a grid
>>>> http://www.w3.org/TR/wai-aria-practices-1.1/#grid
>>>> Once inside a grid the screen reader should automatically switch to
>>>> application/forms mode passing keys through to the webpage.
>>>> Then you can set up keyboard listeners to respond to the arrow key
>>>> presses.
>>>> For the JQuery script see this example of an accessible date picker:
>>>> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
>>>> I workd with a developer to create this. As it was done in 2014 when
>>>> the grid role was poorly supported we used role="application" to force
>>>> the application mode, I believe that is no longer necessary.
>>>>
>>>>
>>>>
>>>> On 6/22/18, Brandon Keith Biggs < <EMAIL REMOVED> > wrote:
>>>>> Hello,
>>>>> Here is a good design for a calendar:
>>>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%
>>>> 20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
>>>>>
>>>>> If you want to add in appointments, tell the user how many
>>>>> appointments
>>>>> there are each day and allow them to hit enter to see what is on that
>>>>> day
>>>>> and escape to exit back to the date picker.
>>>>> Thanks,
>>>>>
>>>>> Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
>>>>>
>>>>>
>>>>> On Fri, Jun 22, 2018 at 6:23 AM Tim Harshbarger <
>>>>> <EMAIL REMOVED> > wrote:
>>>>>
>>>>>> Instead of using role="application", it would be better to use an
>>>>>> ARIA
>>>>>> design pattern that more closely matched the interaction.
>>>>>>
>>>>>> The thing with role="application" is that, while it puts screen
>>>>>> reader
>>>>>> users in forms mode, it doesn't really tell us how to get around the
>>>>>> application. So using role="application" for one part of the page is
>>>> not
>>>>>> likely to inform screen reader users that pressing the up and down
>>>>>> arrow
>>>>>> keys will move from meeting to meeting and pressing the left and
>>>>>> right
>>>>>> arrow keys will move between days.
>>>>>>
>>>>>> A listbox might work because a screen reader user will expect the up
>>>>>> and
>>>>>> down arrow keys to move up and down the list. Unfortunately, there
>>>>>> is
>>>>>> also
>>>>>> an expectation that using the left and right arrow keys will do the
>>>>>> same
>>>>>> exact thing as using the up and down arrow keys. Users would not
>>>>>> expect
>>>>>> the left and right arrow keys to move between days. If you used a
>>>>>> listbox,
>>>>>> you likely would need to explicitly inform users of what the left and
>>>>>> right
>>>>>> arrow keys do differently.
>>>>>>
>>>>>> To me, this sounds more like a grid. In a grid, there would likely
>>>>>> be
>>>> a
>>>>>> better expectation that the up and down arrow keys would move within
>>>>>> the
>>>>>> day while the left and right arrow keys move between days.
>>>>>>
>>>>>> Thanks,
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>>>>> Behalf Of <EMAIL REMOVED>
>>>>>> Sent: Friday, June 22, 2018 1:27 AM
>>>>>> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
>>>>>> Subject: [EXTERNAL] [WebAIM] Navigation in application mode
>>>>>>
>>>>>> Hi all.
>>>>>>
>>>>>> I have a dev who is doing something really non-standard. As far as I
>>>>>> understand the issue at this point of time. He wants to use the
>>>>>> up/down
>>>>>> arrow to move between meetings. The left and right arrow moving
>>>>>> between
>>>>>> the
>>>>>> days. Using non-application mode will not work due to screen readers
>>>>>> as
>>>>>> far
>>>>>> as I can tell. But he wants use the application role to achieve this.
>>>>>> These
>>>>>> UI I am referring to have buttons for next and prior day. The
>>>>>> meetings
>>>>>> from
>>>>>> memory are not in any UI element like a list.
>>>>>>
>>>>>> Any ideas how this can be achieved without using application mode?
>>>>>>
>>>>>>
>>>>>> How does the javascript keyboard event handle keyboard navigation
>>>>>> when
>>>> it
>>>>>> is
>>>>>> not on an element. Do you have to apply the keyboard event to the
>>>>>> body
>>>> of
>>>>>> the html and track from there?
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>
>>>>>>
>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>
>>>>> >>>>> >>>>> >>>>> >>>>>
>>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
>
>
>
>
> From: Isabel Holdsworth < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] keeping jaws focus on a link after page load
> Date: October 26, 2018 at 12:28:01 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Are the search results structured in a way that makes it easy for the
> user to navigate to the first result, say by flagging them up with an
> H1 heading or something to that effect?
>
> If so, then users shouldn't find it too difficult to get back to where
> JAWS started reading from. Most screenreader users will be comfortable
> with this type of scenario, and may not need any extra help.
>
> On 20/06/2018, Tim Harshbarger < <EMAIL REMOVED> > wrote:
>> That sounds like a better approach to me. I also believe it is possible to
>> change the JAWS settings so it doesn't automatically start reading the page
>> contents. If that is the case, you might also want to share that with
>> them.I wonder if it would be useful to provide FreedomScientific with a
>> suggestion to just notify the user that the new page has loaded instead of
>> automatically start reading the page. Of course, that probably is only a
>> good suggestion if my assumption is correct that the feature was originally
>> introduced to let the user know that the new page has been loaded.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Nick Allan
>> Sent: Wednesday, June 20, 2018 5:53 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: [EXTERNAL] Re: [WebAIM] keeping jaws focus on a link after page
>> load
>>
>> Thanks, I actually did try the setTimeout but I suspect if you don't wait
>> long enough for jaws to actually stop speaking it continues to adjust the
>> keyboard focus.
>> I think I'll probably just tell our users when these search screens popup
>> that they should just press ctrl to stop speech straight away. If you do
>> that, the focus does set correctly.
>>
>> Nick
>>
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Tim
>> Harshbarger
>> Sent: Tuesday, 19 June 2018 10:59 PM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] keeping jaws focus on a link after page load
>>
>> I don't think there is anything you can do from the application/site side of
>> things to avoid JAWS doing that short of setting a javascript timer when the
>> page loads and having it set the focus back to the element.
>>
>> Something like:
>>
>> // Trigger the focus event 500 ms after the timer starts.
>> Window.setTimeout(() => {
>> Document.querySelector("[autofocus]");
>> }, 500);
>>
>> I haven't tested that code so it might not work. Also, this code assumes
>> the element that receives focus is using the autofocus element.
>>
>> However, I'm not sure I would use the code in a page even if it works. You
>> already probably know this, but this seems to me like an intentional screen
>> reader feature. I'm always reluctant to do something that interferes with a
>> screen readers intentional behaviours since it alters the behavior that the
>> screen reader user likely expects.
>>
>> Thanks,
>> Tim
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Nick Allan
>> Sent: Sunday, June 17, 2018 10:32 PM
>> To: <EMAIL REMOVED>
>> Subject: [EXTERNAL] [WebAIM] keeping jaws focus on a link after page load
>>
>> Hi all
>> I've got a situation where I have a link that causes a new browser window to
>> open, on that window are 2 frames one showing search results. Keyboard focus
>> automatically goes to the link for the first search result in the 2nd frame,
>> but because it's a new page load, Jaws automatically starts reading, which
>> then moves the focus off that first search result if you don't press the
>> ctrl key quickly enough to stop jaws reading.
>> Other than modifying the jaws configuration to not automatically start
>> reading on page load. Does anyone have any suggestions on what could be done
>> here to stop jaws automatically reading and moving the focus?
>>
>> Nick
>>
>>
>> Nick Allan
>> Access Technology Technical Lead
>> Business Transformation
>> Vision Australia
>> 454 Glenferrie Rd Kooyong VIC 3144
>>
>> M: +614 2957 4051 T: +613 9864 9293 (I: 341293)
>> E: <EMAIL REMOVED>
>> www.visionaustralia.org
>>
>> [Vision Australia. Blindness. Low Vision. Opportunity. - logo]
>>
>> [Vision Australia. Winner of the Australian HR Award for Best Workplace
>> Diversity and Inclusion Program. - logo]
>>
>> The history, culture, diversity and value of all Aboriginal and Torres
>> Strait Islander peoples are recognised, acknowledged and respected.
>>
>> >> >> http://webaim.org/discussion/archives
>> >> >> >> http://webaim.org/discussion/archives
>> >> >> >> >> >> >> >> >> >>
>
>
>
>
> From: Isabel Holdsworth < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Another table sort question
> Date: October 26, 2018 at 12:38:57 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> I find this table quite counter-intuitive. In the top row, pressing
> Tab moves across the row. But as soon as the focus moves out of the
> headers and into the data, pressing Tab moves row by row, not column
> by column.
>
> And having to listen to all of that sorting information as I move
> around the data would drive me crazy if I had to spend much time
> working with tables like this.
>
> If the instruction were provided by the ARIA-DESCRIBEDBY instead of
> the ARIA-LABELLEDBY attribute, I wonder if the instructions would
> still be spoken by screenreaders when the user moves to a new column
> and the screenreader reports the column header? If not, then IMO this
> would be a great solution.
>
> On 19/06/2018, Jeremy Echols < <EMAIL REMOVED> > wrote:
>> I'm looking at "Datatables" (see URL https://datatables.net/), and it seems
>> to have done a lot to try and be accessible, but to me it seems a bit iffy.
>> The context changes depending how I navigate the table, and depending on the
>> context it may announce "Position" or "Position: activate to sort column
>> ascending" as the header as I browse the cells.
>>
>> Am I just not used to the right way to do a more interactive grid, or are
>> these quirks going to present problems in the real world?
>> >> >> >> >>
>
>
>
>
> From: Steve Faulkner < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Deque AXE plugin
> Date: October 26, 2018 at 5:08:38 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Axe is available on github https://github.com/dequelabs/axe-core
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
>
> On Fri, 26 Oct 2018 at 07:44, < <EMAIL REMOVED> > wrote:
>
>> All,
>>
>>
>>
>> Does anyone know if you can get access to the source of AXE for Firefox and
>> Chrome? As I would like to see if I could make a modification to the
>> plugin.
>> That is, to save the results to a JSON. Also with AXE Core API which you
>> can
>> include in your source. Is it possible to create this as a code which you
>> insert into a page which is already loaded and you don't have direct access
>> to the source?
>>
>>
>>
>>
>>
>> Sean
>>
>>
>>
>> >> >> >> >>
>
>
>
>
> From: Sudheer Babu < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Keyboard accessible HTML5 video player
> Date: October 26, 2018 at 6:30:51 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Thanks for the response Jeff!
>
> I have raised a bug - https://bugzilla.mozilla.org/show_bug.cgi?idI4175
> against Firefox and got it duplicated. There is already an open issue on it.
>
> - Sudheer
>
> On Wed, Oct 24, 2018, 10:50 PM Jeff Gutsell < <EMAIL REMOVED> > wrote:
>
>> Hi,
>> The Firefox keyboard support for the audio and video default players is
>> disappointing but might be passable.
>> The Enter and spacebar keys will toggle the play/pause button. The up and
>> down arrow keys will control the volume. I know of no technique to announce
>> the elapsed time.
>>
>> Jeff Gutsell
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Sudheer Babu
>> Sent: Tuesday, October 23, 2018 11:28 PM
>> To: <EMAIL REMOVED>
>> Subject: [WebAIM] Keyboard accessible HTML5 video player
>>
>> Hi all,
>>
>> First of all thanks to all the amazing people here who are helping alot on
>> the accessibility issues.
>>
>> We have an ask where the HTML5 video player to be used which has proper
>> keyboard focus on controls and also keyboard accessible.
>>
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video
>>
>> The default HTML5 video player renders differently on Firefox and Chrome
>> and the keyboard focus on player controls works fairly better on chrome.
>>
>> Can someone suggest how can the keyboard accessibility be achieved for the
>> default video players on Firefox?
>>
>> Thanks in advance!
>>
>> Sudhy.
>> >> >> >> >>
>> >> >> >> >>
>
>
>
>
> From: "Henry, Michael (IntelliDyne)" < <EMAIL REMOVED> >
> Subject: [WebAIM] Accessible Tree Navigation?
> Date: October 26, 2018 at 7:31:04 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Hello, all.
>
> I hope this isn't too rudimentary of a question, but I've been trying to unravel how to properly use ARIA to make a left navigation (structured like tree navigation) accessible via keyboard.
>
> The more I read, though, the more turned around I get. Seems like every article I read uses a slightly different approach or different ARIA attributes, and none of them describe the exactly situation (markup structure) that we have. Hopefully you guys can help?
>
>
> Here's the basic structure of our navigation tree with my best current guess at appropriate use of ARIA:
>
> <h2 ID="tree_label" class="visiblyHidden">Submenu for current section</h2>
> <ul class="LV1" role="tree" aria-labelledby="tree_label">
> <li class="hasChildren">
> <div role="treeitem" aria-selected="true | false" aria-expanded="true | false" tabindex="0 | -1" >
> <span class="icon" role="button" onclick=""></span> [clicking here toggles the submenu open/closed]
> <a href="/Plans/Eligibility">Eligibility</a>
> </div>
> <ul role="group" class="LV2" >…</ul>
> </li>
> </ul>
>
> I'm afraid I'm so confused on this that I don't know exactly what to ask. But I think what I need to know is:
> 1) should the <li> or the <div> have the role of "treeitem"?
> 2) should the <li> or the <div> have the ARIA attributes?
> 3) should all elements that we intend to make focusable (including the <span.icon>, which expands/collapses the child <ul>) receive tabindex=-1 (making them part of the Roving Tabindex)?
> 4) should it be the first Root Node ("Eligibility" in this example) that should have tabindex=0 on page load?
> 5) where is the appropriate place for the "aria-selected" attribute?
> 6) where is the appropriate place for the "aria-expanded" attribute?
>
> Thank you so much for any help.
> Mike
>
>
> ---
> Mike S. Henry
> Creative Services Lead
> IntelliDyne Contract Employee
> Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
> Desk: (703) 882-3962
>
>
>
>
>
> From: "Karlen Communications" < <EMAIL REMOVED> >
> Subject: [WebAIM] GitHub and the Colour Contrast Analyzer latest version
> Date: October 26, 2018 at 7:46:10 AM PDT
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
>
>
> Can anyone help me run the latest version of TPG's Colour Contrast Analyzer
> on a Windows 10 with all updates computer?
>
>
>
> I downloaded the Windows version from GitHub. I did find a bug from 21 days
> ago that states that the GitHub installer trips Windows Defender and you get
> a message that is supposed to say "Run Anyway" or "Don't Run."
>
>
>
> I'm using Windows 10 with all current updates and there is no "Run Anyway"
> button, just a "Don't Run" button.so I can't run the latest version of the
> Colour Contrast Analyzer even if I choose to run as administrator.
>
>
>
> I've never had problems with any download of this tool before and I was
> teaching a class in accessible document design at the time I asked students
> to download the tool. I was the only one who could not run the thing! I had
> to use an older version which I thankfully had on my computer.
>
>
>
> So, can anyone tell me how to run the latest version of the Colour Contrast
> analyzer on Windows 10?
>
>
>
> Cheers, Karen
>
>
>
>
>
> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Accessible Tree Navigation?
> Date: October 26, 2018 at 8:53:47 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Mike
>
> First of, my general experience is that using trees and menus is a lot
> of coding for developers and confusing for users.
> If you canfit your paradigm into a simple disclosure/accordion pattern
> you often save yourself a lot of head aches and your users too.
>
> <button id="x" aria-expanded="false">Menu x</button>
> <<div role="group" aria-labelledby="x" class="hidden"> <!-- this is
> the group of elements displayed user clicks the button>
> <ul>
> <li><a href="#">Link 1</a></li>
> ...
> </ul>
> </div>
> (the list construct is optional).
>
> When user clicks the button its aria-expanded attribute is set to
> "true" and the group is displayed.
>
> You can have the menu close when user moves focus out of it, as long
> as you set the trigger button's aria-expanded back to false.
> I the menu has a submenu you can use the same approach.
>
> This approach doesn't require juggling multiple ARIA attributes and
> writing JavaScript to manage keyboard focus.
>
> If you still need to do that consult the ARIA Authoring Practices spec
> https://www.w3.org/TR/wai-aria-practices-1.1/
> it is the ultimate/best guide for designing these widgets.
> In section 3 explore either the menu button or the tree widget.
> HTH
> -B
>
>
> On 10/26/18, Henry, Michael (IntelliDyne) < <EMAIL REMOVED> > wrote:
>> Hello, all.
>>
>> I hope this isn't too rudimentary of a question, but I've been trying to
>> unravel how to properly use ARIA to make a left navigation (structured like
>> tree navigation) accessible via keyboard.
>>
>> The more I read, though, the more turned around I get. Seems like every
>> article I read uses a slightly different approach or different ARIA
>> attributes, and none of them describe the exactly situation (markup
>> structure) that we have. Hopefully you guys can help?
>>
>>
>> Here's the basic structure of our navigation tree with my best current guess
>> at appropriate use of ARIA:
>>
>> <h2 ID="tree_label" class="visiblyHidden">Submenu for current section</h2>
>> <ul class="LV1" role="tree" aria-labelledby="tree_label">
>> <li class="hasChildren">
>> <div role="treeitem" aria-selected="true | false"
>> aria-expanded="true | false" tabindex="0 | -1" >
>> <span class="icon" role="button"
>> onclick=""></span> [clicking here toggles the submenu open/closed]
>> <a href="/Plans/Eligibility">Eligibility</a>
>> </div>
>> <ul role="group" class="LV2" >…</ul>
>> </li>
>> </ul>
>>
>> I'm afraid I'm so confused on this that I don't know exactly what to ask.
>> But I think what I need to know is:
>> 1) should the <li> or the <div> have the role of "treeitem"?
>> 2) should the <li> or the <div> have the ARIA attributes?
>> 3) should all elements that we intend to make focusable (including the
>> <span.icon>, which expands/collapses the child <ul>) receive tabindex=-1
>> (making them part of the Roving Tabindex)?
>> 4) should it be the first Root Node ("Eligibility" in this example) that
>> should have tabindex=0 on page load?
>> 5) where is the appropriate place for the "aria-selected" attribute?
>> 6) where is the appropriate place for the "aria-expanded" attribute?
>>
>> Thank you so much for any help.
>> Mike
>>
>>
>> ---
>> Mike S. Henry
>> Creative Services Lead
>> IntelliDyne Contract Employee
>> Supporting Enterprise Infrastructure (formerly Military Health System
>> Cyberinfrastructure Services - MCiS)
>> Desk: (703) 882-3962
>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
>
>
>
>
> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Another table sort question
> Date: October 26, 2018 at 8:58:08 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> My approach to sortable tables is to use the aria-sort attribute when
> appropriate on the <th> cells, and code the actionable headers as
> buttons.
>
> <table>
> <tr>
> <th aria-sort="ascending">Name</button></th>
> <th><button>Age</th>
> <th>Address</th>
> </tr>
> ...
> <table>
>
> You may need to add a sentence such as "to sort the table by the
> values in a column, click the button in the column header.
> You can use a visual indicator hidden from screen readers to indicate the sort.
> This approach enables a screen reader user to know what can be sorted,
> indicates activate sort and does not add a ton of unnecessary text to
> every column header, important because users have to listen to them
> all the time.
>
>
> On 10/26/18, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
>> I find this table quite counter-intuitive. In the top row, pressing
>> Tab moves across the row. But as soon as the focus moves out of the
>> headers and into the data, pressing Tab moves row by row, not column
>> by column.
>>
>> And having to listen to all of that sorting information as I move
>> around the data would drive me crazy if I had to spend much time
>> working with tables like this.
>>
>> If the instruction were provided by the ARIA-DESCRIBEDBY instead of
>> the ARIA-LABELLEDBY attribute, I wonder if the instructions would
>> still be spoken by screenreaders when the user moves to a new column
>> and the screenreader reports the column header? If not, then IMO this
>> would be a great solution.
>>
>> On 19/06/2018, Jeremy Echols < <EMAIL REMOVED> > wrote:
>>> I'm looking at "Datatables" (see URL https://datatables.net/), and it
>>> seems
>>> to have done a lot to try and be accessible, but to me it seems a bit
>>> iffy.
>>> The context changes depending how I navigate the table, and depending on
>>> the
>>> context it may announce "Position" or "Position: activate to sort column
>>> ascending" as the header as I browse the cells.
>>>
>>> Am I just not used to the right way to do a more interactive grid, or are
>>> these quirks going to present problems in the real world?
>>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
>
>
>
>
> From: glen walker < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Navigation in application mode
> Date: October 26, 2018 at 10:08:45 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Perhaps I'm missing something but if you're in application mode and want to
> navigate character by character, then you switch out of application mode,
> right? Ins+Z with JAWS and Esc with NVDA.
>
> On Fri, Oct 26, 2018 at 1:21 AM Isabel Holdsworth < <EMAIL REMOVED> >
> wrote:
>
>> So if I wanted to interrogate an item within a grid using a
>> screenreader, say for example to read a name or number character by
>> character, how would I do that if the arrow keys are being passed to
>> the application?
>>
>>
>
>
>
>
> From: "Henry, Michael (IntelliDyne)" < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Accessible Tree Navigation?
> Date: October 26, 2018 at 10:50:17 AM PDT
> To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Thanks, Birkir.
>
> Unfortunately, our markup is not going to change, but I will try again to digest the spec. It's pretty far outside my wheel house.
>
> What I did gather, though, is that the "aria-expanded" attribute ought to be on the <span.icon>, which serves as the trigger to expand/collapse the sub menu?
>
>
> - mh
>
> ---
> Mike S. Henry
> Creative Services Lead
> IntelliDyne Contract Employee
> Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
> Desk: (703) 882-3962
>
> > From: WebAIM-Forum < <EMAIL REMOVED> > on behalf of Birkir R. Gunnarsson < <EMAIL REMOVED> >
> Sent: Friday, October 26, 2018 11:53:47 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Accessible Tree Navigation?
>
> Mike
>
> First of, my general experience is that using trees and menus is a lot
> of coding for developers and confusing for users.
> If you canfit your paradigm into a simple disclosure/accordion pattern
> you often save yourself a lot of head aches and your users too.
>
> <button id="x" aria-expanded="false">Menu x</button>
> <<div role="group" aria-labelledby="x" class="hidden"> <!-- this is
> the group of elements displayed user clicks the button>
> <ul>
> <li><a href="#">Link 1</a></li>
> ...
> </ul>
> </div>
> (the list construct is optional).
>
> When user clicks the button its aria-expanded attribute is set to
> "true" and the group is displayed.
>
> You can have the menu close when user moves focus out of it, as long
> as you set the trigger button's aria-expanded back to false.
> I the menu has a submenu you can use the same approach.
>
> This approach doesn't require juggling multiple ARIA attributes and
> writing JavaScript to manage keyboard focus.
>
> If you still need to do that consult the ARIA Authoring Practices spec
> https://www.w3.org/TR/wai-aria-practices-1.1/
> it is the ultimate/best guide for designing these widgets.
> In section 3 explore either the menu button or the tree widget.
> HTH
> -B
>
>
> On 10/26/18, Henry, Michael (IntelliDyne) < <EMAIL REMOVED> > wrote:
>> Hello, all.
>>
>> I hope this isn't too rudimentary of a question, but I've been trying to
>> unravel how to properly use ARIA to make a left navigation (structured like
>> tree navigation) accessible via keyboard.
>>
>> The more I read, though, the more turned around I get. Seems like every
>> article I read uses a slightly different approach or different ARIA
>> attributes, and none of them describe the exactly situation (markup
>> structure) that we have. Hopefully you guys can help?
>>
>>
>> Here's the basic structure of our navigation tree with my best current guess
>> at appropriate use of ARIA:
>>
>> <h2 ID="tree_label" class="visiblyHidden">Submenu for current section</h2>
>> <ul class="LV1" role="tree" aria-labelledby="tree_label">
>> <li class="hasChildren">
>> <div role="treeitem" aria-selected="true | false"
>> aria-expanded="true | false" tabindex="0 | -1" >
>> <span class="icon" role="button"
>> onclick=""></span> [clicking here toggles the submenu open/closed]
>> <a href="/Plans/Eligibility">Eligibility</a>
>> </div>
>> <ul role="group" class="LV2" >…</ul>
>> </li>
>> </ul>
>>
>> I'm afraid I'm so confused on this that I don't know exactly what to ask.
>> But I think what I need to know is:
>> 1) should the <li> or the <div> have the role of "treeitem"?
>> 2) should the <li> or the <div> have the ARIA attributes?
>> 3) should all elements that we intend to make focusable (including the
>> <span.icon>, which expands/collapses the child <ul>) receive tabindex=-1
>> (making them part of the Roving Tabindex)?
>> 4) should it be the first Root Node ("Eligibility" in this example) that
>> should have tabindex=0 on page load?
>> 5) where is the appropriate place for the "aria-selected" attribute?
>> 6) where is the appropriate place for the "aria-expanded" attribute?
>>
>> Thank you so much for any help.
>> Mike
>>
>>
>> ---
>> Mike S. Henry
>> Creative Services Lead
>> IntelliDyne Contract Employee
>> Supporting Enterprise Infrastructure (formerly Military Health System
>> Cyberinfrastructure Services - MCiS)
>> Desk: (703) 882-3962
>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
>
>
> > > >