freedomscientific / standards-support Goto Github PK

Summary

1. Launch JAWS 18.0.4534.

2. Go to this page
   https://ibma.github.io/Va11yS/WCAG_HTML/H85_example1.html

3. Open the dropdown with ALT+arrow, then use down arrow key to traverse the list.

Expected result

JAWS announces the headings, thereby helping JAWS user understand the grouping that is obvious to sighted users.

The page being tested shows that this was shown to work in the past. It also refers to
WCAG 85, which is this: https://www.w3.org/TR/WCAG20-TECHS/H85.html

Actual result

JAWS announces the list items (which are reachable via keyboard, so this is normal), but does not announce the optgroup labels/headings (e.g., Fruits, Vegetables, Baked Goods).

Operating System and version

Windows 10 Pro

Browsers

a) Firefox Quantum (57.0.4)
b) Chrome 63.0.3239.132

JAWS Version

18.0.4534

Summary

Aria-describedby text is not read on the elements which have default focus on a webpage, it is specifically observed when the element has role="dailog"

Expected result

The aria-describedby text should be read when focus is on that element irrespective of how the focus is set on it.

Actual result

The aria-describedby text is not read on an element when it has default focus.

Additional Information

Check the codepen url https://gist.github.com/ShardulGhusey/22c785937882491ca609b095778de114

JAWS version and build number

Jaws 2018

Operating System and version

Windows 10

Browser and version:

IE 11 -- 11.674

Summary

Jaws does not recognise the ARIA table, row, columnheader, rowheader, and cell roles in Edge.

1. Navigate to the test case, which contains two tables (one ARIA and one HTML)
2. Use the t shortcut key to move between tables
3. Use the arrow keys to move to the first table, then standard table navigation commands to interact with it (control alt left/right/up/down)

Expected resultJaws should recognise two tables on the page. Jaws should be able to use standard table navigation commands to interact with both tables.

Actual result

Jaws does not recognise the first (ARIA) table, and standard table navigation commands do not work.

Example

http://design-patterns.tink.uk/aria-tables/

Additional Information

JAWS version and build number

Jaws 2018.1801.81

Operating System and version

Windows 10 64bit

Browser and version:

Edge 41

Summary

1. Go to https://codepen.io/anon/pen/NaJaPr
2. Navigate through the elements

Expected result

Each of the links is read only once.

Actual result

Only the link outside the list is read once. In IE, both JAWS 16 and JAWS 18 have troubles reading the link when it is located inside a list. The first link in a given list item, then the other content inside that item and finally the same link again is read.

Example

https://codepen.io/anon/pen/NaJaPr

Additional Information

JAWS version and build number

18.0.2945, 16.0.4474

Operating System and version

Windows 10 Enterprise 10.0.10586 Build 10586

Browser and version:

Internet Explorer 11

Summary

Jaws does not treat a button element (<button> or other elements that map to a button role or a button role created with ARIA) with the aria-haspopup attribute as a button but as a menu.
e.g.
<button aria-haspopup="true">Actions</button>
(see also the menu button examples in the ARIA Authoring Practices guide).

If you try to navigate to menu buttons in the Jaws virtual cursor with the button shortcut "b" you won't find it, only if you use "c" that navigates to dropdowns and menus.

This is problematic because a menu button is a button until it has been activated.
This is also problematic because aria-haspopup has a lot of other token values (such as grid or dialog) that do not cause menus to open when a button with aria-haspopup is activated.

ON a page with a menu button and Jaws running:

1. Hit the "b" key to navigate to the menu button.

Expected result

Jaws should locate the button and announce the role as "button has menu" or 'button, submenu".
(Jaws not announcing other values of aria-a-haspopup wil be filed in a separate issue).

Actual result

Jaws does not find the button (it does not recognize it as a button, but as a menu).

Example

The APG 1.1 navigation menu

Additional Information

JAWS version and build number

All versions of Jaws and browsers.

Operating System and version

All versions of Windows (not verified for Windows 10).

Browser and version:

All browsers.

Summary

aria-describedby text not getting read when html element has "title" attribute also.

Expected result

The aria-describedby text should be read irrespective of any other attribute on it.

Actual result

The aria-describedby text is not getting read when the same html element has "title" attribute in it.

Example

https://gist.github.com/ShardulGhusey/b9fd9f55e2f1f6590f0a74854b1be3e2

Additional Information

aria-describedby text not getting read when "title" is present in the element, once we remove the title tag the aria-describedbby text is read correctly.

JAWS version and build number

Jaws 2018

Operating System and version

Windows 10

Browser and version:

IE 11

Summary

Potential gap in how instructional cues are processed by JAWS 18 - IE 11 and JAWS 18 - Edge when using aria-controls in https://test-cases.tink.uk/aria-expanded/index.html (example by @LJWatson)

Example:

1. Go to https://test-cases.tink.uk/aria-expanded/index.html
2. Tab to the button 'Tequila'
3. Activate the button

Expected result

• Screenreader should give the acc name of the control + current state + how to activate + instructions on getting to controlled element (in this case pointer to aria-controls)

Actual result

• JAWS 18 / IE11 / Win 10 / 64 bit: JAWS 18 speaks 'Tequila, use JAWS key + Alt + M to move to controlled element, expanded.'
• JAWS 18 / Edge / Win 10 / 64 bit: Does not give shortcut cues to get to controlled element, but indicates the use of spacebar to activate. 'Tequila button expanded, to activate press spacebar.'

Example

• https://test-cases.tink.uk/aria-expanded/index.html

Additional Information

Operating System and version

• Win 10 / 64 bit

Browser and version:

• JAWS 18.0.2531 / IE 11 / IE Edge 25

Summary

When interacting with a text input with a datalist, JAWS announces the input as having a popup, but with no other announcements on how to interact with the popup. When hitting the down arrow to attempt to interact with the datalist, the datalist is opened, but JAWS instead moves focus to the next element in the DOM.

If using JAWS + Chrome, the input is announced as a combo box and JAWS states "to change the selections, use the arrow keys".

Expected result

On pressing down arrow, it should be expected that the first item of the datalist would receive focus, as is the case when JAWS is not running.

Chrome + JAWS works as expected.

Actual result

When hitting the down arrow, the datalist opens, but JAWS instead moves focus to the next element in the DOM. In the test page, that element is an <h3> with text "code". If the up arrow or SHIFT + Tab are used to return JAWS focus to the input, the down arrow key can now be used to enter the datalist options.

Example

https://thepaciellogroup.github.io/AT-browser-tests/test-files/datalist.html

Additional Information

JAWS version and build number

JAWS 18.0.4321
Issue previously reported pertaining to JAWS 16

Operating System and version

Windows 10 Pro v.1703 64-bit

Browser and version:

Firefox 56.0
Chrome 61.0.3163

Summary

JAWS doesn't announce the associated titles/captions of forms and regions when navigating to one of its interactive elements

Example

1. Go to https://codepen.io/anon/pen/xpxqod
2. There are two examples:
   • simple form
   • nested forms
3. Try navigating one of their interactive elements using TAB key

Expected result

Entering a form region with its associated name to be announced before reading the information of the currently focused interactive element.

Actual result

1. Simple form - only information about the focused element is announced by JAWS. Form information and its name are omitted.
2. Nested forms - only information about the focused element is announced by JAWS. Main and nested form information and their names are omitted.

Additional Information

This example was tested with the following screen reader and browser combinations:

1. JAWS + Chrome - works
2. JAWS + IE11 - doesn't work
3. NVDA + Chrome - works
4. NVDA + IE11 - works

JAWS version and build number

JAWS 18.0.4352.400

Operating System and version

Windows 10 Enterprise version 1607 (build 14393.1944)

Browser and version:

Internet Explorer 11.1944.14393.0 (update versions 11.0.49)

When arrowing down through a web page, elements with aria-describedby cause a flash message on braille displays that is not spoken aloud. The display shows "msg Use JawsKey+Alt_R to read descriptive text". Since this is a flash message, it eventually does get replaced by the text read aloud, but this delay causes a significant slow down in navigating pages with braille alone.

Steps to reproduce:

1. Go to https://twitter.com/home
2. Do a JAWS find for "Reply"
3. This happens for reply buttons which have a reply count greater than 0. If the first "Reply" button applies to a tweet which has not been replied to, press F3 to search again.

Expected behavior:
The speech should read aloud "Reply X button". The braille display should show "Reply X". (Where X represents the number of replies.)

Actual behavior:
Speech reads aloud "Reply X button", but the braille display shows "msg Use JawsKey+Alt+R to read descriptive text".

Operating System: Windows Version 10.0.16299 Build 16299
Browser: Firefox ESR - 52.5.0 64-bit
Browser: Chrome Version 63.0.3239.84 (Official Build) (32-bit)
JAWS: Version 2018 (build 1712.10 ILM)

Summary

Implicit labels (wrapped around fields) without a for="ID" can cause issues reading menus and trees elsewhere on the page. In some instances, the text of a tree item is not read at all, rendering a tree navigation inaccessible.

Expected result

The text of the menuitems and treeitems should be read.

Actual result

The label gets read for each menu item or treeitem. In some instances, the text of the treeitem itself doesn't get read.

Additional Information

JAWS version and build number

Example: JAWS 18.0.4104

Browser and version:

Example: IE 11.0.96

Example:

Code marked up as a menu and tree but does not have the CSS and JS to operate beyond the top item
https://codepen.io/LauraFO/full/zELENZ/

Summary

Jaws with IE11 doesn't read the contents of area vox

Example:

1. https://jsfiddle.net/22pLsujt/
2. Tab to go to textbox.

Expected result

jaws should read the contents the text-area.

Actual result

just reading text-box editing.

Example

https://jsfiddle.net/22pLsujt/

Additional Information

jaws 18 with IE11

Operating System and version

Browser and version:

Summary

I have a sample form which includes an error message which is briefly displayed if the user tabs past a certain form field without typing anything into the field. The issue appears to only affect JAWS and IE (details of which I will provide shortly) - the below demo works as expected in other environments (such as JAWS + FF and JAWS + Google Chrome).

To replicate this issue:

1. Go to https://codepen.io/graemecoleman/pen/xpwGag
2. Tab to the "Please enter some text:" form control.
3. Press Tab without entering anything into the field.
4. Visually, the text "You need to enter some text" will be immediately displayed above the field. This text is wrapped inside a container. The alert role is injected when the text is injected.

Expected result

JAWS announces the error text once.

Actual result

JAWS announces the error text twice - once when the error is injected into the page, and once again when it is removed.

Example

https://codepen.io/graemecoleman/pen/xpwGag

Additional Information

JAWS version and build number

• JAWS 18.0.4532
• JAWS 2018 build 1710.42 ILM

Operating System and version

• Windows 10 Home
• 64-bit operating system

Browser and version:

Internet Explorer 11.125.16299.0

Summary

On Internet Explorer 11, if a form element and a label are placed inside a container which has the role of "dialog", JAWS repeats the label, times the number of children nodes in the label, when the form element receives focus via Tab. i.e: Having two spans inside the label, makes it repeat the label twice, for three spans, it repeats three times and so on.

This only happens when Tab is used for navigation. Both implicit and explicit labels are subject to the same bug.

Expected result

Each child node should only be included once when calculating the label of an input.

Actual result

Each child node is included multiple times when calculating the label of an input.

Example

https://codepen.io/wizzyfx/pen/MoNVrP
Screen Capture: https://streamable.com/g4biq

Additional Information

JAWS version and build number

JAWS 18.0.4321

Operating System and version

Windows 10 64-Bit

Browser and version:

IE 11

Summary

Jaws does not indicate aria-expanded state consistently in Edge.

1. Open the test case
2. Use b to move Jaws' focus to the "Tequila" button
3. Note that Jaws does not announce the aria-expanded state
4. Use the arrow keys to move Jaws' focus away and back to the button
5. Note that Jaws does not announce the aria-expanded state
6. Use the tab key to move focus away from the button and back again
7. Note that Jaws announces the aria-expanded state
8. Use space or enter to activate the button
9. Note that Jaws continues to announce the aria-expanded state as "collapsed

Expected result

• Jaws should indicate the aria-expanded state regardless of method used to focus on the button
• Jaws should indicate the "expanded" state when the value of aria-expanded is changed

Actual result

See steps above.

Example

https://test-cases.tink.uk/aria-expanded/index.html

Additional Information

JAWS version and build number

Jaws 2018.7012.10

Operating System and version

Windows 10 64bit

Browser and version:

Edge 41

Summary

JAWS 18 does not read the native browser validation error message tooltip in IE11 (have not tested for other versions).

Expected result

The tooltip should be announced on appearance, and also announced when the input field receives focus and/or associated with the input label.

Actual result

The error message is completely ignored.

Example

Example URL:
https://www.webpagefx.com/blog/images/assets/cdn.sixrevisions.com/demos/0345-new_html5_form_input_types/new-html5-form-input-types.html?

Steps to reproduce:

• Open JAWS and IE11
• Navigate to example URL above
• Browse to the example for "email" input type
• Enter an invalid email address and press "Enter"
• Observe the appearance of a tooltip indicating an invalid entry
• Attempt to locate this tooltip by browsing forwards and backwards around the element with JAWS

Additional Information

JAWS version and build number

18.0.4350

Operating System and version

Windows 10 Professional (10.0.16299 Build 16299)

Browser and version:

Internet Explorer 11 (11.14.16299.0)

Summary

The aria-haspopup entry in the ARIA 1.1 spec allows various values (not just true/false).
aria-haspopup allows values menu, tree, grid, listbox and dialog. The attribute should be used on controls that, when activated, display those widgets.
This should be announced by Jaws, but Jaws announces all values of aria-haspopup as "has menu".

in test file navigate to the different buttons and (with the tab key or "C" because Jaws does not treat buttons with aria-haspopup as buttons, see another issue filed on this repo).

Expected result

Jaws should announce the type of widget indicated by the value or aria-haspopup (e.g. "opens a listbox" "opens a dialog".

Actual result

jaws only announces "button menu" for all the buttons.

Example

(see attached file)

Additional Information

JAWS version and build number

All versions of Jaws.

Operating System and version

All versions.

Browser and version:

Tested in IE and Firefox, all versions (except Edge).

aria-haspopup.txt

JAWS accessibility test.txt

Summary

Steps:

1. open the attached HTML in IE11 and JAWS
2. Jaws reads out the name of the checkbox and buttons as blank.
   P.S: It reads expected names at times, but not always.

Expected result

Read the names of the checkbox and buttons as provided (Condition/Add Filter/Add Related Entity Filter)

Actual result

Jaws reads 'blank' for both the buttons and checkbox

Example

Attached HTML file

Additional Information

JAWS version and build number

Version 2018 (build 1710.42 ILM)

Operating System and version

Windows 10

Browser and version:

IE11

Summary

1. Go to https://codepen.io/anon/pen/MOMLbr
2. Click on the "Only the first tooltip is read" title and press TAB only once. You should now be focusing the div with role="heading", where the first two buttons are located in.

Expected result

Either none, or all tooltips inside that container are read out.

Actual result

Only the first tooltip is read out.

This is only happening when the elements are located inside a container with role="toolbar", which is placed inside another container with role="heading".

There are two other examples in the codepen link. One with the buttons placed directly inside the div with role="heading" and one with that div missing (only placed inside div with role="toolbar"). In the first example, both tooltips are read out and in the second - neither one.

I would expect one of those outputs for my case - either read all tooltips or just skip them completely.

Example

https://codepen.io/anon/pen/MOMLbr

Additional Information

The reason behind role="application" on the body, is explained in this issue:
#13

JAWS version and build number

18.0.4350

Operating System and version

Windows 10 Enterprise
Version: 1607

Browser and version:

IE 11.1944.14393.0

Summary

My OS and JAWS are Dutch. Automatic language detection is switched on. Synthesizer is vocalizer expressive.
When I go to a page with lang="en", its contents is correctly spoken with the English voice. But when the contents of a live region is spoken, this is done with the default (Dutch) voice instead of the English one.

1. Go to https://www.gov.uk/
2. type "water" in the search field and submit
3. Under "filter by": check a check box
4. wait until JAWS reads the contents of the live region. It says something like "684 results found "

Expected result

"684 results found" to be read with the same English voice that is reading all the other contents on this web page

Actual result

"684 results found" is spoken with the default voice (In my case Belgian Dutch Ellen)

Additional Information

JAWS version and build number

JAWS 18.0.4104 (but the issue is not specific for this version)

Operating System and version

Windows 7 64-bit

Browser and version:

IE11 and also in Firefox 56

Chrome: 65.0.3322.3 Canary 64-bit
Chrome: 63.0.3239.132 (Official Build) (64-bit)
Chrome: 55.0.2841.0 (Official Build) (64-bit)
Firefox: 52
JAWS: 2018
NVDA: 2017.4

Steps to repro:

1. With JAWS running, visit http://ncamftp.wgbh.org/sp/tests/simpleLiveRegion/simpleLiveRegionDemo.html
2. Press the "Add One and Display" button multiple times
3. Notice that text is added, but JAWS does not speak it
4. Try the same with NVDA
5. Notice that NVDA speaks the added text
6. Try JAWS in Firefox
7. Notice that JAWS speaks the added text

Expected: JAWS should read added text in Chrome

Actual: JAWS does not read added text.

original bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=802337

Implicit labels/radios do not work as expected in IE Edge and IE 11

See test code:
https://codepen.io/jasonday/pen/zppLyG

• Using keyboard enter Implicit label fieldset
• use arrows to navigate between options
  • In IE Edge, each radio is announced "1 of 1"
  • In IE 11
    • No count of number of options is announced (for implicit or explicit)
    • If a selection has been made (implicit), then each option is announced as the first option label. In example demo code, each option is announced as "color 1"

Expected result

• I expect each option to announce it's index in the count total
• I expect labels to be announced appropriately

JAWS 2018 1712.10 ILM

Windows 10

Summary

JAWS 18 is not reading aria-labelledby and aria-describedby element contents when attribute is added to role="dialog"

1. Go to https://codepen.io/lifter035/project/full/AxKWap/
2. "Open dialog" button will be focused but JAWS will not announce even that (another issue?)
3. Activate the button to open dialog
4. Dialog will autofocus to first radio button in the group

Expected result

JAWS should announce dialog aria-labelledby and aria-describedby elements contents when dialog is shown (display:none; style changed to display:block;)

Actual result

JAWS is reading only focused radio button label
JAWS is reading only close button label if dialog opened via "Open dialog - focus on close" button
Also if I change role="dialog" to role="alertdialog" JAWS is announcing dialog title while dialog is still "display:none;"

JAWS version and build number

Example: JAWS 18.0.4104

Operating System and version

Example: Windows 10 Enterprise Evaluation 64-bit

Browser and version:

Example: Internet Explorer 11 (haven't tested others)

Summary

In Chrome, JAWS is not reading out the associated label for a <select> when I have focus on the select.

Steps:

1. Go to my test page: https://codepen.io/cordelia/pen/bYPYrj
2. Tab to the select dropdown.

Expected result

JAWS should read something like "Test Select, combobox, Option A."

Actual result

JAWS reads "Option A."

Additional Information

I'm not sure if this is specifically a JAWS bug or a Chrome bug or a mix of both. See related Chrome bug 687621.

JAWS version and build number

JAWS Version 18.0.4350

Operating System and version

Windows 10

Browser and version:

Chrome Version 62.0.3239.84

Summary

Name calculation for explicit labels is incorrect when another element is present between the input and the label. In the code sample below, the page content is included in the accessible name. Noticed from 18.0.25XX thru 18.0.4350
In the case below, there is an icon and a div closure tag that are causing the issue. The heading tag is read with the label. When I remove the icon and the enclosing div, the issue resolves.
Also, if focus is set to an element on the page, this newly focused element becomes the Name of the inputs. This occurs with programmatic focus set with JavaScript as well as mouse selections initiated by the user.

example:

<h1>This heading is included in the input label</h1>
<div><input id="firstID" type="checkbox" value="on"><i aria-hidden="true"></i></div>
<label for="firstID"><span id="innerID">Lorem Ipsum</span></label>

Expected result

I expect the label to be "Lorem Ipsum"

Actual result

All content on the page is calculated in the name.

Example

<h1>This heading is included in the input label</h1>
<div><input id="firstID" type="checkbox" value="on"><i aria-hidden="true"></i></div>
<label for="firstID"><span id="innerID">Lorem Ipsum</span></label>

Additional Information

JAWS version and build number

18.0.2530

Operating System and version

Windows 7-10

Browser and version:

IE11, 11.0.46

Summary

Note: I realise this isn't a web-standards issue, but this is the most accessible place to file a JAWS bug.

In Windows high-contrast mode, the license agreement text is bright yellow on a white background, which makes it incredibly hard to read.

Example:

1. Turn on Windows high-contrast mode.
2. Install JAWS / an update to JAWS.
3. After your PC has re-started, you'll be presented with the license agreement window, which contains the license agreement text.

Expected result

Text should be readable and should have a contrast of at least 4.5:1.

Actual result

Text is almost illegible.

Example

Additional Information

JAWS version and build number

JAWS 2018 (build 1712.10 ILM)

Operating System and version

Windows 10 Enterprise

Summary

When a live region is updated and a user is using Zoomtext something should happen. I can envision a number of ways this could be implemented. One or more of the following could be considered

1. Play a sound so the user is aware something was updated
2. Allow a keystroke (in response to the sound) to move zoomtext focus to the live region
3. Allow a keystroke (in response to the sound) to read the live region text - even if the user does not normally have speech output enabled.

There are a number of scenarios where a magnification user would not be easily aware that something had happened outside the field of vision. This would enable a user using magnification to know that something happened (1) and then potentially discover more about what actually happened.

Expected result

I expect live regions to be useful for screen magnification users as well as screen reader users.

Actual result

Nothing

Example

http://www.freedomscientific.com/Training/Surfs-Up/AriaLiveRegions.htm

Additional Information

When the live region updates I would expect a sound and then to allow a keystroke to be pressed to move my focus to that live region.

JAWS version and build number

Zoomtext

Operating System and version

Windows

Browser and version:

All

Summary

The dialog is not read as dialog when opened, though it reads correctly if we click on that dialog.

Expected result

Jaws should read as "Dialog" when dialog opens

Actual result

Jaws not reading as dialog until we click on the dialog.
Note : The focus is on 1 of the element of dialog when it opens even then we need to click inside dialog once.

Example

https://gist.github.com/ShardulGhusey/0ad4efd7e8150b73d3d8608821e27ad3

Additional Information

Verified the behavior on Firefox. It is working fine on Firefox.

JAWS version and build number

Jaws 2018 17.1042 ILM

Operating System and version

Windows 10

Browser and version:

IE 11

Summary

When attempting to navigate a document by landmark regions, I expected JAWS to navigate to forms on the page. However, testing with JAWS 18 and 2018, this was not the case as native form elements are not being surfaced as landmark roles.

Expected result

Expected that form elements would be exposed as a landmark and that froms could be navigated to via region quick keys.

Actual result

Native form elements, and form elements with a set aria-label were not surfaced as landmark regions by JAWS 18 or 2018.

However, JAWS 18 did surface a div role="form" in all browsers tested. JAWS 2018 was similar, but did not surface the role="form" in latest Edge.

Example

Here is a test page for a native form element, a form element with a set aria-label, a div[role="form"], and a control contentinfo` landmark. As noted in the results, this is not an issue unique to JAWS.

Additional Information

JAWS version and build number

JAWS 2018 - build 1712.10
JAWS 18.0.4534

Operating System and version

Windows 10

Browser and version:

IE11, latest Chrome, latest Edge, Firefox ESR

Summary

When I update the value of a form field in a live region JAWS does not read out the label of the form field. Example
https://codepen.io/anon/pen/aVRyxw
Press the "Trigger Update" button

Expected result

I would expect JAWS to read the new value and the label for the form field

Actual result

JAWS just reads the new value

Example

https://codepen.io/anon/pen/aVRyxw
Press the "Trigger Update" button

Additional Information

NVDA & Voiceover (Mac) both read the label as well as the value.

JAWS version and build number

2018 - 1710.42

Operating System and version

Windows 8.1

Browser and version:

Chrome 62

JAWS 2018 on IE11 does not read MathJax content that is in a <label> tag next to a radio button.
Instead it reads "x", "x radio button".

I have tried to find a solution to this issue but couldn't. Having "Supportive MathML" enabled does not change anything. Still reads "x radio button".

This can be reproduce with the following code with version 2.7.2 of MathJax.

<html>
    <head>
        <title>MathJax TeX Test Page</title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta http-equiv="X-UA-Compatible" content="IE=edge" />
        <script type="text/x-mathjax-config">
            MathJax.Hub.Config({
                tex2jax: {inlineMath: [["$","$"],["\\(","\\)"]]}
            });
        </script>
        <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js?config=TeX-AMS_HTML-full"></script>
    </head>
    <body>
        <form>
            <p>
                What is the correct answer?
            </p>
            <label>
                <input type="radio" name="answer" value="0" />
                <div>
                    \( 0.48 \)
                </div>
            </label>
            <label>
                <input type="radio" name="answer" value="1" />
                <div>
                    \( 1.16 \)
                </div>
            </label>
            <label>
                <input type="radio" name="answer" value="2" />
                <div>
                    \( 12.92 \)
                </div>
            </label>
            <label>
                <input type="radio" name="answer" value="3" />
                <div>
                    \( 13.53 \)
                </div>
            </label>
        </form>
    </body>
</html>

Any ideas what could be causing this?

I have also opened an issue on the MathJax side:
mathjax/MathJax#1874

Thanks,
Ludo.

Summary

arrow keys in JAWS 2018 do not read line by line inside table cells, even with table mode off

Example:

1. Go to http://davidmacd.com/test/table-lists.html
2. press "T" to go to the table.
   Move to cell col 2 row 2 using table keys. Press down arrow to read the list item.

Expected result

should read the first list item inside the cell.

Actual result

Went to the cell below.

Example

above

Additional Information

Arrow keys are moving cell to cell in all technologies, even with table layer off

JAWS version and build number

2018 build 1712 10iLM

Operating System and version

WIN 10

Browser and version:

Chrome, Edge... probably others... but also happens in Word tables.

On the first live region, the updated text is on the root of the element with aria-live.
On the second live region, the updated text is on a span child of the element with aria-live.

https://codepen.io/anon/pen/NXLLdr

Additional Information

JAWS version and build number

Tested on Jaws 17, 18.0.4534 and 2018.1712.10

Operating System and version

Windows 10

Browser and version:

IE 11

Jaws reads aria-label of all the buttons in a div at once when one of its button gets focus for the first time
Please check the mentioned codepen url

Expected result

The aria-label of button which has focus should only be read

Actual result

The aria-label of all the buttons in a div are read at once for the first time when one of its button gets focus

Additional Information

Verified the the behavior with Jaws + Firefox & it is working as expected.
In the codepen just remove the divs inside the buttons
then the Jaws will read it correctly. It is the div which affects jaws only on IE 11.

JAWS version and build number

Jaws version 2018(build 1710.36ILM)

Operating System and version

Windows 10

Browser and version:

IE 11 -- 11.674

`https://gist.github.com/ShardulGhusey/e2c610d4b328d4d93e7bee2463e42831

Summary

This is a two-parter: one is a JAWS bug, the other is an observation of an IE bug.

JAWS reads all <header> tags as banner regions, regardless of the <header> nesting level. According to the spec on header, only those scoped to the body of a document or application should get the banner role, and that any document/app SHOULD only have 1 banner role.

1. Go to https://tink.uk
2. 'r' around the regions OR just arrow through the page content

The page has <article>s and within those are <header>s, which should not receive banner roles.

Expected result

I should only encounter the main, nav, complimentary landmarks on the page.

Actual result

After the main landmark I encounter "article banner" as landmark stops using the landmark shortcut 'r'. Arrowing through the page reads out both the articles and their "banners" inside them.

Additional Information

Interestingly, Internet Explorer seems has some bug which interlaces with this-- in both JAWS and NVDA, all <header>s are read out as banners. NVDA does not do this in Firefox nor Chrome. JAWS however calls all <header>s banners in all browsers, not just IE. This means testing whether the JAWS bug is fixed requires checking all the browsers.

JAWS version and build number

18.0.4534

Operating System and version

Windows 7 Professional/Service Pack 1

Browser and version:

Tested in IE11, Firefox ESR (52.something), Chrome 63.

Summary

1. Go to https://codepen.io/anon/pen/rYzEMo
2. Press TAB until you reach the link

Expected result

Only the text of the link (Test 1) is read out.

Actual result

Everything inside the list item is read out. If the p tag in the example is replaced by span, label, etc. it would still be included.

Example

https://codepen.io/anon/pen/rYzEMo

Additional Information

JAWS version and build number

18.0.4350, 16.0.4474

Operating System and version

Windows 10 Enterprise 10.0.14393 Build 14393

Browser and version:

Internet Explorer 11

Summary

Sorry, I don't know whether this is a Twitter bug or JAWS, but it manifests using JAWS only so I thought I'd start here first. Apologies if it turns out to be a Twitter thing.

Essentially, JAWS is not reading the button label for the "Add emoji" and "Add a GIF" buttons in Twitter's compose DM (Direct Message) modal when you use keyboard Tab key to tab to it.

It only announces that there is a menu (due to aria-haspopup attribute) but not the text within the inside the element. Code for the button element seems correct (it has offscreen text) so it could be an inheritance problem...? Or since it's reading the menu role, a conflict with aria-haspopup attribute?

I have verified that this problem does not exist in NVDA + Firefox nor VoiceOver and Safari.

Expected result

When tabbing through the compose message modal, JAWS should read the accessibility text as coded in the offscreen within the button.

Actual result

JAWS announces only "button. menu. press space to activate the menu".

Example

1. Using the configuration listed below, visit twitter.com
2. Login with an account that has at least one follower
3. Navigate to the follower's profile page (click "followers" link > follower's name link)
4. Click on the "Message" button to send a Direct Message (DM) to the follower
5. On the compose message overlay, use the keyboard Tab key to to navigate to the Add emoji button (visually positioned within the message text-entry field), and the Add a GIF button positioned to the right of the text-entry field.
6. Observe what JAWS reads for each button

Additional Information

Code for the "Add emoji" button:

HTML:
<button type="button" class="EmojiPicker-trigger js-dropdown-toggle js-tooltip u-textUserColorHover" data-delay="150" aria-haspopup="true" data-original-title="Add emoji"> <span class="Icon Icon--smiley"></span> <span class="text u-hiddenVisually"> Add emoji </span> </button>

CSS for hiding the button text offscreen:

.u-hiddenVisually { border: 0 !important; clip: rect(1px,1px,1px,1px) !important; font-size: 1px !important; height: 1px !important; overflow: hidden !important; padding: 0 !important; position: absolute !important; width: 1px !important; }

JAWS version and build number

Have reproduced in JAWS 2018 build 1710.42 as well as JAWS 18.0.0350

Operating System and version

Windows 10 Professional (10.0.16299 Build 16299)

Browser and version:

Internet Explorer 11 (11.14.16299.0)

The behavior for navigating by region in web documents seems to have changed. Some regions place you on the first line of the region, while others focus the word which begins the container. Articles don't ever seem to gain focus, although they are read "article" ... "article end".

Steps to reproduce:

1. Visit: https://applevis.com/blog/apple-braille-ios-news/apple-releases-ios-112-bringing-many-fixes-braille-and-voiceover-users
2. Navigate down the page using just the r key.

Expected:
In JAWS 18.0.4352 one hears:
banner
Form
search region
navigation region
You are here navigation region
main region
banner
article
banner
navigation region
article
banner
navigation region

Actual:
In JAWS 2018 Build 1710.42 one hears:
AppleVis
Log in/Register
Search this site
navigation region
You are here navigation region
main region
Apple Releases iOS 11.2; Bringing Many Fixes for Braille and VoiceOver Users
Submitted by AppleVis on 2 December, 2017 and last modified on 2 December, 2017
navigation region
Siri voice fixes
navigation region
Read text in Photos
navigation region

The wording at the top of the blog post "Apple Releases iOS...", which is focused one press of the letter r after the main region, is what JAWS 18 identifies as a banner. This can also be seen with one more press, which yields "Submitted by AppleVis..." In the previous version banner was called out, and focus was placed on the word banner. This is not noted because it is wrong, but to demonstrate the difference in functionality.
What is wrong, is that pressing r never results in "article", which is what would have been expected in JAWS 18.0.4352.

Operating System: Windows Version 10.0.16299 Build 16299
Browser: Firefox ESR - 52.5.0 64-bit

Summary

Brief description of the issue. Please list any specific steps.
JAWS is not reading the position of the items in the listbox even when role="listbox" is provided on the conatiner and role="option" is provided to the child elements in the listbox container in the HTML markup.
Also JAWS is not reading the state of the button (Selected/ Non-Selected) even when attribute "aria-selected" is provided in the HTML markup.

Expected result

JAWS should read the position of the items in the listbox container like ( 1 of 4, 2 of 4, etc..) and should read "selected" when aria-selected="true" and "non-selected" when aria-selected="false"

Actual result

It does not reads anything, nor the position nor the state (Selected/ Non-Selected).

Example

Summary

If a list item contains nested HTML, JAWS 18 won't announce it as one "chunk" of content. Instead, it only announces the content of the first nested element, resulting in the arrow keys being needed to discover the other nested items.

Example:

1. Go to: https://codepen.io/fstorr/full/jGZGBa/
2. Use the i key to find the next list item.
3. JAWS 18 will announce the content of the first nested element, for example the visually-hidden "completed step:" <span> element, and then stop.

Expected result

I would expect JAWS to announce the full content of the list item as NVDA 2017.3 does.

Actual result

JAWS 18 only announces the content of the first nested HTML element.

Example

Test case on CodePen: https://codepen.io/fstorr/full/jGZGBa/

Additional Information

JAWS version and build number

JAWS 18.0.4321

Operating System and version

Windows 10 Enterprise 64-bit

Browser and version:

Chrome 61, IE11, Firefox 56.0

Summary

When a button element is referenced with a label (either by label's for or button's aria-labelledby). The text of a button is not announced by JAWS.

Example:

1. Go to https://jsfiddle.net/ovy0t0ky/2/
2. You will see all the use cases that this issue describes:

• Case 1 - button only
• Case 2 - label + button (button is referenced to the label via label's for attribute)
• Case 3 - label + button (button is referenced to the label via its aria-labelledby attribute)
• Case 4 - label + button (button is referenced both via label's for attribute and its aria-labelledby attribute)

Expected result

• Case 1 - The role and text of the button to be announced by JAWS
• Case 2 - The text of the referenced label + button's text and role to be announced by JAWS
• Case 3 - The text of the referenced label + button's text and role to be announced by JAWS
• Case 4 - The text of the referenced label + button's text and role to be announced by JAWS

Actual result

• Case 1 - The button's text is announced but its role is always omitted by JAWS.
• Case 2 - The text of the referenced label is announced but button's text and role are omitted by JAWS
• Case 3 - The text of the referenced label is announced but button's text and role are omitted by JAWS
• Case 4 - The text of the referenced label is announced but button's text and role are omitted by JAWS

Additional Information

JAWS version and build number

JAWS 18.0.4350.400

Operating System and version

Windows 10 Enterprise
v. 1607 (OS build: 14393.1884)

Browser and version:

IE 11.1884.14393.0
Update version 11.0.48 (KB4047206)

JAWS 18 precedence levels

JAWS 18 speaks the value of aria-label, instead of aria-labelledby IDREFs.

Example:

1. Go to https://codepen.io/devpant/pen/GybdQq?editors=1000
2. Screen reader users -- in virtual cursor mode, use the headings list to navigate to 'JAWS 18 precedence levels' and tab twice to the text box control.

Expected result

JAWS 18 should speak the aria-labelledby IDREFs 'Set one Label set one instructions.'

Actual result

JAWS 18 speaks value of aria-label, 'aria-label.'

Example

https://codepen.io/devpant/pen/GybdQq?editors=1000

Additional Information

JAWS version and build number

JAWS 18; 18.0.2531

Operating System and version

Win 10; 64 Bit

Browser and version:

IE 11

Summary

According to ARIA 1.1

• The attribute value MUST allow a token list as the value;
• The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element.

However, JAWS doesn’t go past unknown role values, and ignores any valid supported role that may appear after the 1st position in the token list.

Example:

1. Go to https://s.codepen.io/stevef/debug/wKrdYQ (test pen from @stevefaulkner)
2. test 2 and 4 aren’t processed as main areas.

Expected result

Test 2 and 4 should be announced like test 1, 3, and 5.

Unknown, or otherwise illegal roles (such as abstract roles "section" and "landmark") should be ignored, and the first non-abstract role "main" should be taken into account.

Actual result

The role "main" is not applied to test 2 and 4.

Example

See @stevefaulkner’s "multiple role values tests" pen

Additional Information

See also TPG’s testing results.

JAWS version and build number

JAWS 2018, build 1712.10 ILM.

Operating System and version

Windows 10 64bit.

Browser and version:

IE 11 (11.1198.14393.0)

Summary

JAWS does not speak any contents in the JavaScript alert dialog in Chrome. Nothing is announced when it appears and insert+b does not read the dialog.

Example:

1. Go to any page with a JavaScript alert or confirm dialog
2. Press tab
3. Press insert+b
4. Note nothing is announced

Expected result

What did you expect to happen?

Actual result

JAWS should automatically speak the contents of the dialog and standard dialog commands should work.

Example

Additional Information

JAWS version and build number

JAWS >=2018

Operating System and version

Windows 7

Browser and version:

Chrome - latest build.

Summary

JAWS 2018 doesn't read text in Visual studio 2017 creation wizards text fields

Stepts to reproduce:

1. Open Visual Studio 2017.
2. File / new / Project.
3. Tab until name text edit.
4. Write the project name and try to read the text box content by using arrows.

Expected result

JAWS should read the text box content.-

Actual result

JAWS read "blank" as the textbox is empty, what it's false.

Additional Information

JAWS version and build number

JAWS 2018.1710.42

Operating System and version

Windows 10 creators update

Summary
In the case that a parent element of an interactive element, which when focused cause JAWS to enable forms mode, results in JAWS announcing all the text content of the parent element on focus.
The cause of this appears to be the presence of an aria-hidden=false attribute on the parent element. When this is removed it no longer occurs.

Example code:

 Using JAWS 2018 and IE 11: Any text that is a descendent 
  <div> of an element with aria-hidden=false
    <div> will get announced as one big label for
      <div> the following text box, when the text box gets focus via the tab key.
        <div><input type="text" aria-label="and thats not right">
        </div>
      </div>
    </div> 
  </div>
</div>

Steps to reproduce:

1. With JAWS 2018 running Go to https://s.codepen.io/stevef/debug/xYwQao in IE11
2. Once the page has loaded press the TAB key to focus the first input type="edit"
3. Listen to what JAWS announces, then press the TAB key again to focus the second `input type="edit" and listen to what JAWS announces.

Expected result
When first textbox gets focus the aria-label is announced:

"and that's not right"

When second textbox gets focus the aria-label is announced:

"and that's right"

Actual result
When first textbox gets focus

"Using JAWS 2018 and IE 11: Any text that is a descendant
of an element with aria-hidden=false
will get announced as one big label for
the following text box, when the text box gets focus via the tab key. "

is announced, then the
aria-label is announced:

"and that's not right"

When second textbox gets focus the aria-label is announced:

"and that's right"

Additional Information
JAWS 2018
Windows 10
Internet Explorer 11

Note: The cause can only be understood by reviewing the FSDOMserver output as the accessibility tree exposed in IE 11 is correct.

Summary

Jaws does not recognise the aria-current attribute in Edge.

Expected result

Jaws should announce "current" when (actual or virtual) focus moves to an element with the aria-current attribute. where one of the tokens has been used (page, date, time, location, step), Jaws should append the token to the announcement.

Actual result

Jaws does not announce current (with or without a token value).

Example

http://design-patterns.tink.uk/aria-current/index.html

Additional Information

JAWS version and build number

Jaws 2018.1801.81

Operating System and version

Windows 10 64bit

Browser and version:

Edge 41

Summary

My OS and JAWS are Dutch. Automatic language detection is switched on. Synthesizer is vocalizer expressive.
When reading a page with lang="en", its contents is correctly spoken with the English voice. JAWS announces the role of elements such as link, image, heading level. This is nicely done in Dutch and with the default Dutch voice. This is true as long as this announcement preceeds the actual text. But when it is behind, then it is spoken by the English voice that is used to speak the contents.

Example

1. Go to https://www.gov.uk/
2. arrow down until you reach the first heading level 1
3. JAWS reads with the Dutch voice "kopniveau 1" (which is the correct Dutch translation of heading level 1), followed by the actual text of the heading "welcome to gov.uk. The latter is spoken with the English voice. So this is how it should be.
4. Go back to top with ctrl+home and press h to reach the same heading.
5. Now you hear "welcome to gov.uk, kopniveau 1". The problem is that both parts are spoken with the English voice. It should switch to the Dutch voice to speak "kopniveau 1".

This seems consistent for semantic info that is spoken after the actual text. For some reason JAWS announces the word link before reading the link text but it reads the value of a button and after that it says that it is a button. Since the link announcement is before, the voice is switched corrrectly. Since the button announcement is at the end, there is no voice swapping and the word knop (translation of button) is spoken with the English voice.

Expected result

JAWS to use the correct voice to speak its own information (such as button, link, heading level, tab selected, checkbox not checked etc). It should not matter whether this info is at the beginning of the string or at the end.

Actual result

Only correct when the JAWS info is read first. When the info follows other text from the web page, JAWS keeps talking with the voice that was used to speak the contents.

Additional Information

JAWS version and build number

JAWS 18.0.4104 (but the issue exists since a long time. It gets more and more annoying with all the new aria announcements)

Operating System and version

Windows 7 64-bit

Browser and version:

IE11 and also in Firefox 56 (but older versions as well)

Summary

When a toggle button (a <button> element with an aria-pressed attribute) is activated while Jaws is running in manual forms mode, Jaws goes into forms mode (when button is pressed).

Forms mode is necessary in complex widgets where the author is responsible for keyboard navigation, but toggle buttons are not complex widgets, they act like checkboxes and toggling a checkbox does not trigger forms mode, neither does clicking a button.
Toggle buttons are frequently used to filter search results or as a replacement for a checkbox.

to reproduce

1. Rename the attached file to a .html extension and open in Firefox or Chrome (or open the Code pen , thanks Steve).
2. With Jaws running, switch to manual forms mode (in the browser, press Jaws-key and v, type "forms" in the search, locate "forms mode" by pressing arrow down, press spacebar until 'manual" is selected, then tab over to the "ok" button and confirm.
3. Navigate to and activate the "I agree button".
4. Forms mode is triggered (and Jaws announces "pressed').

If you activate the button in IE11 the pressed state is not announced automatically, (and the button is not announced as a "collapsed button".

Browsers

Tested with Firefox and chrome on Windows 8, IE11 does not expose the aria-pressed attribute.
ariapressedtest.txt

Summary

JAWS does not recognize role="buTTon" as a 'push button' in IE11 although it is exposed as a 'push button' in MSAA

Steps to reproduce:

1. Go to https://s.codepen.io/stevef/debug/YrLwwE
2. move focus to the first focusable element, observe what JAWS announces
3. move focus to the second focusable element, observe what JAWS announces

Expected result

JAWS announces both as buttons

Actual result

JAWS only announces the the second element as a button

Example

https://s.codepen.io/stevef/debug/YrLwwE

Additional Information

JAWS version and build number

JAWS 18.0.4104

Operating System and version

Windows 10 Home 64-bit

Browser and version:

IE 11

Related Firefox bug: aria ROLE values are case sensitive