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
>>>>>>
>>>>>>
>>>>>>