E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Meacham, Steve - FSA, Kansas City, MO
Date: Wed, Jun 07 2017 3:34PM
Subject: JAWS 18 - safe to upgrade
No previous message | Next message →

I'd heard many statements back when JAWS 18 was released that it wasn't stable and/or usable enough to upgrade to. Therefore we're still using/supporting JAWS 17. Have the issues been sufficiently addressed to commit to JAWS 18 yet?

Steven Meacham, ICT Accessibility Program Manager
USDA Farm Service Agency
+1 (816) 926-1942<tel:+18169261942>
For program support email = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

From: JP Jamous
Date: Wed, Jun 07 2017 3:39PM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

18 is safe to update to, but you will get the most out of it if you are using Windows 10. I have never had any issue with it on both Windows 7 and 10.

From: Andrews, David B (DEED)
Date: Thu, Jun 08 2017 10:01AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

Well this is a pretty subjective statement and like with most things in IT, it depends. I suspect there are multiple variables, like video, other software you are running etc. Personally, my observation is that JAWS 18 isn't more stable, or unstable then other recent releases. It has been a little unstable for a while, but it is also better at recovering from some situations. I have seen much more instability of late, in Internet Explorer 11, I have a lockup once a day or more. And ... Chrome and Firefox aren't perfect easier ... so what is a blind guy to do?

Dave

p.s. Upgrade one machine, and just try. I always leave one previous JAWS version, sometimes two, on all my machines at work, and at home!




David Andrews | Chief Technology Officer
Minnesota Department of Employment and Economic Development
State Services for the Blind
2200 University Ave West, Suite 240, St. Paul MN 55114
Direct: 651-539-2294
Web | Twitter | Facebook

From: Joy Relton
Date: Thu, Jun 08 2017 10:20AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

I found JAWS 17 much less stable than JAWS 18 myself.

From: J. Isaac
Date: Thu, Jun 08 2017 12:10PM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

I haven't had any issues with Shaws 18 on the web. There are the standard Microsoft office issues though. Should be safe to upgrade.
HTH,

==J


> On Jun 8, 2017, at 9:01 AM, Andrews, David B (DEED) < = EMAIL ADDRESS REMOVED = > wrote:
>
> Well this is a pretty subjective statement and like with most things in IT, it depends. I suspect there are multiple variables, like video, other software you are running etc. Personally, my observation is that JAWS 18 isn't more stable, or unstable then other recent releases. It has been a little unstable for a while, but it is also better at recovering from some situations. I have seen much more instability of late, in Internet Explorer 11, I have a lockup once a day or more. And ... Chrome and Firefox aren't perfect easier ... so what is a blind guy to do?
>
> Dave
>
> p.s. Upgrade one machine, and just try. I always leave one previous JAWS version, sometimes two, on all my machines at work, and at home!
>
>
>
>
> David Andrews | Chief Technology Officer
> Minnesota Department of Employment and Economic Development
> State Services for the Blind
> 2200 University Ave West, Suite 240, St. Paul MN 55114
> Direct: 651-539-2294
> Web | Twitter | Facebook
>
>
>
>

From: Mallory
Date: Sat, Jun 10 2017 10:49AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

I had a large bug in 16 (where while the Dutch voice read out iframe
content, the English voice acted as though the iframes weren't on the
page at all!) which forced me to upgrade to 18. So far, the stuff I
normally test is acting as expected, and I've had no crashes yet. With
16 it was not unusual for opening complex powerpoints (with mathML etc
in them) and watching 16 slow to a crawl and then fall back to the
default Dutch voice. 18 deals with these better, for me.

cheers,
_mallory

On Thu, Jun 8, 2017, at 08:10 PM, J. Isaac wrote:
> I haven't had any issues with Shaws 18 on the web. There are the standard
> Microsoft office issues though. Should be safe to upgrade.
> HTH,
>
> ==J
>
>
> > On Jun 8, 2017, at 9:01 AM, Andrews, David B (DEED) < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Well this is a pretty subjective statement and like with most things in IT, it depends. I suspect there are multiple variables, like video, other software you are running etc. Personally, my observation is that JAWS 18 isn't more stable, or unstable then other recent releases. It has been a little unstable for a while, but it is also better at recovering from some situations. I have seen much more instability of late, in Internet Explorer 11, I have a lockup once a day or more. And ... Chrome and Firefox aren't perfect easier ... so what is a blind guy to do?
> >
> > Dave
> >
> > p.s. Upgrade one machine, and just try. I always leave one previous JAWS version, sometimes two, on all my machines at work, and at home!
> >
> >
> >
> >
> > David Andrews | Chief Technology Officer
> > Minnesota Department of Employment and Economic Development
> > State Services for the Blind
> > 2200 University Ave West, Suite 240, St. Paul MN 55114
> > Direct: 651-539-2294
> > Web | Twitter | Facebook
> >
> >
> >
> >

From: Steve Green
Date: Fri, Jun 16 2017 12:44AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

I have found two new issues with JAWS 18 that can render websites completely unusable under certain circumstances. I don't know how widespread this problem will be, but it has affected two of the three websites I have been testing in the last two weeks.

In one case, it appears that the problem is caused by a new heuristic that JAWS 18 is using. The other may also be a new heuristic or it may just be a bug. In both cases, JAWS 17 works fine.

The first issue occurs when a textbox or textarea is inside a <div> element that has any "aria" attribute or a "tabindex" attribute. JAWS concatenates all the text (including labels for other form controls) and uses it as the label for the textbox or textarea. This can be fixed by changing the <div> element to a <section> element.

The other issue requires two factors to occur. First, there needs to be a <label> element with no "for" attribute - obviously this should not happen but it seems to be quite common. Secondly, there needs to be a form control that does not have an explicit label. In the website I was testing, there was a JavaScript combobox replacement in which the options were list items with role="option", which was sufficient to cause this bug / behaviour. When these two factors occur, JAWS uses the contents of the <label> element as the label for the form controls even though they are completely unrelated. In my case it meant that all the options in the combobox appeared to be the same.

I have built trivially simple test pages to verify that these issues are not specific to my clients' websites. I am therefore surprised that I can't find any mention of them on the web, since they must affect a lot of websites.

Steve Green
Managing Director
Test Partners Ltd

From: Jonathan C. Cohn
Date: Fri, Jun 16 2017 6:01AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

The first sounds like what the standards recommends for name calculation. The second would definitely be a defect.

Best wishes,

Jonathan Cohn

> On Jun 16, 2017, at 2:44 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> I have found two new issues with JAWS 18 that can render websites completely unusable under certain circumstances. I don't know how widespread this problem will be, but it has affected two of the three websites I have been testing in the last two weeks.
>
> In one case, it appears that the problem is caused by a new heuristic that JAWS 18 is using. The other may also be a new heuristic or it may just be a bug. In both cases, JAWS 17 works fine.
>
> The first issue occurs when a textbox or textarea is inside a <div> element that has any "aria" attribute or a "tabindex" attribute. JAWS concatenates all the text (including labels for other form controls) and uses it as the label for the textbox or textarea. This can be fixed by changing the <div> element to a <section> element.
>
> The other issue requires two factors to occur. First, there needs to be a <label> element with no "for" attribute - obviously this should not happen but it seems to be quite common. Secondly, there needs to be a form control that does not have an explicit label. In the website I was testing, there was a JavaScript combobox replacement in which the options were list items with role="option", which was sufficient to cause this bug / behaviour. When these two factors occur, JAWS uses the contents of the <label> element as the label for the form controls even though they are completely unrelated. In my case it meant that all the options in the combobox appeared to be the same.
>
> I have built trivially simple test pages to verify that these issues are not specific to my clients' websites. I am therefore surprised that I can't find any mention of them on the web, since they must affect a lot of websites.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>

From: Steve Green
Date: Mon, Jun 19 2017 10:21PM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | Next message →

I am no expert on the accessible name calculation, but I can't see any reason why text in the parent elements would be appended to a form control's label given that the form control has an explicit label. The following is a trivial example that exhibits this behaviour.

<p><label for="name">Name</label>
<textarea id="name" row="2"></textarea></p>
<div aria-hidden="false">
<p>Details</p>
<p><label for="age">Age</label>
<textarea id="age" row="2" aria-label="Rank"></textarea></p>
<div>
<p><label for="height">Height</label>
<textarea id="height" row="2" aria-label="Height"></textarea></p>

When navigating down the page using the Tab key (not virtual cursor), JAWS 18 incorrectly announces the Age textarea as "Details Age" and correctly announces the Height textarea as "Height".

Curiously, the reverse happens when navigating up the page. JAWS 18 correctly announces the Age textarea as "Age" and incorrectly announces the Height textarea as "Details Height".

Can anyone explain this behaviour, or is it a JAWS bug, as I expect?

Note that the issue does not occur if the aria-hidden attribute is removed from the <div> element. The issue still occurs if the aria-hidden attribute is replaced with a tabindex attribute.

Steve

From: Jonathan Avila
Date: Tue, Jun 20 2017 5:34AM
Subject: Re: JAWS 18 - safe to upgrade
← Previous message | No next message

Steve, while aria-hidden false is supposed to have no effect - we have encountereed the same issues with its use and JAWS. It is a bug that we also seee occasionally.

Jonathan

Sent from my iPhone

> On Jun 20, 2017, at 12:22 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> I am no expert on the accessible name calculation, but I can't see any reason why text in the parent elements would be appended to a form control's label given that the form control has an explicit label. The following is a trivial example that exhibits this behaviour.
>
> <p><label for="name">Name</label>
> <textarea id="name" row="2"></textarea></p>
> <div aria-hidden="false">
> <p>Details</p>
> <p><label for="age">Age</label>
> <textarea id="age" row="2" aria-label="Rank"></textarea></p>
> <div>
> <p><label for="height">Height</label>
> <textarea id="height" row="2" aria-label="Height"></textarea></p>
>
> When navigating down the page using the Tab key (not virtual cursor), JAWS 18 incorrectly announces the Age textarea as "Details Age" and correctly announces the Height textarea as "Height".
>
> Curiously, the reverse happens when navigating up the page. JAWS 18 correctly announces the Age textarea as "Age" and incorrectly announces the Height textarea as "Details Height".
>
> Can anyone explain this behaviour, or is it a JAWS bug, as I expect?
>
> Note that the issue does not occur if the aria-hidden attribute is removed from the <div> element. The issue still occurs if the aria-hidden attribute is replaced with a tabindex attribute.
>
> Steve
>
>