E-mail List Archives
Thread: Identifying if focus is visible
Number of posts in this thread: 5 (In chronological order)
From: mhysnm1964
Date: Fri, Jul 21 2017 12:50AM
Subject: Identifying if focus is visible
No previous message | Next message →
All,
I was wondering if there was any means for a screen reader user to be able
to check to see if the keyboard focus inn the port view was visible and the
colour contrast without referring to the code?
If the code is the only method, I assume javascript can modify the CSS
attribute?
Sean
From: Lovely, Brian (CONT)
Date: Fri, Jul 21 2017 6:36AM
Subject: Re: Identifying if focus is visible
← Previous message | Next message →
Visible is not really possible at this time. I suppose in theory it might be possible, but I don't think there's anything like this available now. Color contrast is very possible, with either a browser plugin like aXe (http://bit.ly/2gPUVvO) or an online tool like http://webaim.org/resources/contrastchecker/ or http://contrast-finder.tanaguru.com/
From: Meacham, Steve - FSA, Kansas City, MO
Date: Tue, Jul 25 2017 1:54PM
Subject: Re: Identifying if focus is visible
← Previous message | Next message →
Not that I know of. This is one reason that accessibility testing also requires someone with good visual acuity. There is no substitution for an eyeball and human cognition for validating some of the requirements.
From: Birkir R. Gunnarsson
Date: Tue, Jul 25 2017 2:10PM
Subject: Re: Identifying if focus is visible
← Previous message | Next message →
james dietz from Level Access developed an audible focus indicator
plug-in for NVDA
dropboxusercontent.com/u/5705342/AudibleFocus%201.0p1.nvda-addon
I've been meaning to test it forever, but have just been too busy with
other things.
I think it is hard to catch visible focus issus as a blind user
(because visible focs can be provided in a lot of ways, and it is so
easy to detect by a sighted user).
Nevertheless, I love the fact that I can have a basic idea of whether
visible focus is a problem or not by running an NVDA plug-in, so
thumbs up for James for taking this initiative.
Give it a spin.
His instructions (sent to the BATS list) are below.
-B
---
Usage:
NVDA+Shift+F = Toggles AudibleFocus on and off. A high A (880hz) means
it's on, and a lower A (440hz) means it's off.
While AF is on, you'll hear one of three tones when focusing each
item. This tone tells you about the last item which was focused.
Low A (220hz) = This object had no visual change when focus was
removed and will be included in the report.
Low E flat (320hz) = This object is off-screen but has been included
in the focus order. (This means that Skip Nav links are caught, too -
I may rethink this feature later)
C (520hz) = Normal - the picture changed when focus was removed, and
the control was on-screen.
Once you turn AudibleFocus off, a report will be generated in [my
documents]AudibleFocus Reports[yyyy-mm-dd_hh-mm-ss)
Your default web browser will also open with the report index loaded.
Known bugs:
- AudibleFocus will generate a partial report if an app which has
been traversed was closed while AF was active.
- AF will generate error messages for some components which don't
expose a location. (your NVDA log will grow as a result of using this
tool 8))
Future versions will:
- Generate separate reports for individual pages viewed in a web
browser, rather than just one single app-level report.
- Prettier sounds
- Automate detection of focus by traversing the window (next-next
version probably)
- Allow you to more-easily change paths where reports are saved,
the padding around the control's image which is captured (currently
10px), and other settings as they're implemented.
Send questions and suggestions to = EMAIL ADDRESS REMOVED = .
On 7/25/17, Meacham, Steve - FSA, Kansas City, MO
< = EMAIL ADDRESS REMOVED = > wrote:
> Not that I know of. This is one reason that accessibility testing also
> requires someone with good visual acuity. There is no substitution for an
> eyeball and human cognition for validating some of the requirements.
>
>
From: Jonathan Cohn
Date: Tue, Jul 25 2017 8:42PM
Subject: Re: Identifying if focus is visible
← Previous message | No next message
Thanks, my IT department just re-imaged my machine without me having a chance to grab NVDA plugins. My reading of the documentation on this plugin, was I thought it would generate a sound if Focus was on an off-screen item. I suppose it could also check that the CSS properties are appropriate. In any case, I plan to download tomorrow.
Best wishes,
Jonathan Cohn
> On Jul 25, 2017, at 4:10 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> james dietz from Level Access developed an audible focus indicator
> plug-in for NVDA
> dropboxusercontent.com/u/5705342/AudibleFocus%201.0p1.nvda-addon
>
> I've been meaning to test it forever, but have just been too busy with
> other things.
>
> I think it is hard to catch visible focus issus as a blind user
> (because visible focs can be provided in a lot of ways, and it is so
> easy to detect by a sighted user).
> Nevertheless, I love the fact that I can have a basic idea of whether
> visible focus is a problem or not by running an NVDA plug-in, so
> thumbs up for James for taking this initiative.
> Give it a spin.
>
> His instructions (sent to the BATS list) are below.
> -B
> ---
> Usage:
> NVDA+Shift+F = Toggles AudibleFocus on and off. A high A (880hz) means
> it's on, and a lower A (440hz) means it's off.
> While AF is on, you'll hear one of three tones when focusing each
> item. This tone tells you about the last item which was focused.
> Low A (220hz) = This object had no visual change when focus was
> removed and will be included in the report.
> Low E flat (320hz) = This object is off-screen but has been included
> in the focus order. (This means that Skip Nav links are caught, too -
> I may rethink this feature later)
> C (520hz) = Normal - the picture changed when focus was removed, and
> the control was on-screen.
>
> Once you turn AudibleFocus off, a report will be generated in [my
> documents]AudibleFocus Reports[yyyy-mm-dd_hh-mm-ss)
> Your default web browser will also open with the report index loaded.
> Known bugs:
> - AudibleFocus will generate a partial report if an app which has
> been traversed was closed while AF was active.
> - AF will generate error messages for some components which don't
> expose a location. (your NVDA log will grow as a result of using this
> tool 8))
>
> Future versions will:
> - Generate separate reports for individual pages viewed in a web
> browser, rather than just one single app-level report.
> - Prettier sounds
> - Automate detection of focus by traversing the window (next-next
> version probably)
> - Allow you to more-easily change paths where reports are saved,
> the padding around the control's image which is captured (currently
> 10px), and other settings as they're implemented.
>
> Send questions and suggestions to = EMAIL ADDRESS REMOVED = .
>
>
> On 7/25/17, Meacham, Steve - FSA, Kansas City, MO
> < = EMAIL ADDRESS REMOVED = > wrote:
>> Not that I know of. This is one reason that accessibility testing also
>> requires someone with good visual acuity. There is no substitution for an
>> eyeball and human cognition for validating some of the requirements.
>>
>>