Im trying to test the screenreader dialogue on my application for 508 compliance. It works mostly how it should except a problem I'm running into is when I navigate element to element the screenreader reads each keystroke like so "TAB" when I want to traverse through my application. How can I turn this off while testing? I'm running JAWS 17.
The problem is when using the arrow keys with some screen reader like NVDA or JAWS. The arrow button doens't trigger anything on the browser, it seems like it's some action on the screen reader like a shortcut.
When you are in browse mode, you use your keyboard to control a cursor, which works basically like in Word. Arrow keys allow to move between characters, words, and lines.A lot of other shortcuts allow to jump directly to headings, buttons, form elements, and other elements.
What is important to keep in mind is that in browse mode, all these shortcuts and in particular including arrow keys are never transmitted to your page. They perform only their reading and moving functions.
When you are in application / focus / form mode, you use tab to move between focusable elements, and there all key press are transmitted to your page, almost as if there was no screen reader at all.However, it's impossible to precisely review ordinary text in this mode.
Both modes are important, and the screen reader user can decide to switch betwen one and the other at any moment, depending on what he/she wants to do.Shortcut to switch with NVDA is Insert+Space, for example.Screen readers also switch automatically on various occasions, trying to guess what the user is going to do next.
The first of all is to make your element focusable with tabindex=0 if it isn't already focusable.For the rest, test, test, test with real screen reader users to see if they well understand how it works or not, and how screen readers behave (ideally, test several screen readers on several platforms).
Be very careful, though: scren readers switch to form mode automatically in several situations, and depending on what you do in response to pressing arrow keys, you may prevent less experienced screen reader users from getting out of your component easily.You need to make sure that, whether you are only performing quite common navigation, or that the user knows that he/she's in a particular situation where arrow keys work differently than normal (for example in a game)
This seems to work well outside of using JAWS but I've found when I open JAWS to read the screen, its own keyboard commands take over such that if I hit the right arrow key, the screen reader will read the next letter in the narration rather than moving to the next slide.
I did some research and found specific keyboard commands for JAWS and in the example above, clicking ALT + Right arrow should allow you to move forward to the next slide. No problem I thought, I'll just change the trigger to accept that command.
Unfortunitly the keyboard command programed in Storyline seems to be overridden by the keyboard command with JAWS. Does anyone know how to marry the two together so that if I use the ALT + right arrow command as a trigger is Storyline, it will actually move the to the next slide? Currently the screen reader says "forward" out loud, but the slides do not advance. I could be missing something simple, I hope...
Storyline doesn't allow the alt + right arrow key to work in preview as a trigger, and we've shared that with our QA team for review, but it does work within the Published output. Have you tested it there?
I did try it out as a published file and put up on SCORM cloud for their sandbox. Perhaps I'm missing something there but upon publishing I did ensure the ALT + arrow key was the trigger and I still found the slide wasn't advancing although JAWS was saying "forward".
Are you able to try it without JAWS enabled just to confirm that the trigger is working? Also I know JAWS is fairly specific in terms of needing to run in the latest version of JAWS, and Internet Explorer - also JAWS needs to be started before the course is started. Additionally are you able to navigate other parts of the course using JAWS and it's just this one trigger that isn't working?
Interestingly enough I tried it without the JAWS reading activated and the "alt + right arrow" didn't seem to work as a trigger, BUT the right arrow on its own seemed to still work (although I changed the trigger to include the ALT + right arrow).
Thanks for sharing your file, and I was able to publish and test it here at SCORM Cloud. I was able to use the ALT + Right arrow key to navigate to the next slide (I only tested that first slide where I saw all the triggers set up) and it worked normally. I didn't run it with JAWS open, but if you want to take a look at my version let me know how it behaves for you. It's also worth noting I was testing in Chrome so I also took a look at it in IE and that key trigger combination did not seem to work there. I was able to use all the other key triggers, but I know that key triggers can be a bit particular as they could be associated with browser actions as well.
I too came across similar problem. I created slide navigation through right and left arrow triggers. The triggers seem to be working fine on a normal browser. However, when I tried to browse the story.html while Jaws was still running, the triggers don't seem to work.
Thanks Ashley for your response. I tested my published story on IE 11 using JAWS 17, as already suggested in another thread. I figured out that keys such arrow keys, which are used by JAWS itself, cannot be used as triggers in SL2, as these keys get overridden by JAWS controls. I ended up using ctrl+backspace and ctrl+enter for my slide navigation triggers.
I am also preparing a tutorial where I need to create keyboard triggers that will allow learners to navigate to the next screen and select images on the screen. Is there a how-to video that you could direct me to? I am struggling with understanding how Jaws works. Is there a Jaws reader that I can download and test my published files?
Codemirror 6 is a complete rewrite of the editor and it does work with screenreaders. We already use Codemirror 6 in the mobile app and will eventually upgrade to Codemirror 6 in the desktop app as well.
I am on obsidian 0.12 as a blind user of the nvda screenreader.
I would love to get in to obsidian, but am still not able to read text back while editing. Will this be fixed? How can we adres such a thing on the roadmap I mean accessibility should be a priority hthese days of all kinds of organisations. HOw can we get this properly adresed on the backlog? And fixed within one of the upcoming sprints?
As I said on the Discord, the app is so close but kind of so far away in terms of accessibility. The interface looks so simple at first glance, and there is quite a bit of keyboard functionality. I wonder if somebody could maybe make plug-ins to help with accessibility? I do not know code very well at all. Either that or perhaps add-ons for NVDA and scripts for Jaws? But I use my phone far more than my computer.
Hi, still the accessibility of obsidian is not good. F.e. in the IOS and IPAD-Version it is not possible to reach the Button for switching Preview/Edit with Voiceover as well as the two other buttons. This means, that a user with screenreader can not switch from edit zu preview at all. Is it possible to fix the accessibility? - should not be too hard.
Michael
Hi, I too am a totally blind user. I just started trying Obsidian a week ago using JAWS 2024 as my screen reader.
I am still seeing a lot of issues that were already reported on this thread. I am very glad that Obsidian moved from codemirror 5 to 6 because codemirror 5 was awful for accessibility.
There are still a lot of accessibility issues with Obsidian, but so far I have figured out work arounds for most issues. I will soon document my findings and post a detailed document on how to use Obsidian with JAWS.
The following list of JAWS keyboard commands or keyboard shortcuts help anyone working in the area of digital accessibility as a reference document. This document also helps developers to check for screen reader conflicts while implementing access keys. These JAWS keyboard commands should work on all Windows based browsers. See the Maxability recommended screen reader Vs browser combination for accessibility.
JAWS is a commercial screen reader by FreedomScientific. If you have not already downloaded the JAWS screen reader for windows, Go to JAWS download page, however read the Freedom scientific terms and conditions of using the software.
Use new Outlook with your keyboard and a screen reader to do the essential basic tasks with Mail. We have tested it with Narrator, JAWS, and NVDA, but it might work with other screen readers as long as they follow common accessibility standards and techniques. You can create and send new emails, read and reply to received emails, search emails, work with attachments, and more.
New Microsoft 365 features are released gradually to Microsoft 365 subscribers, so your app might not have these features yet. To learn how you can get new features faster, join the Office Insider program.
To read through the whole email, with Narrator, press the SR key+Tab. With JAWS and NVDA, press the SR key+Down arrow key. To stop reading, press Ctrl. To close the email and return to the message list, press Esc.
Type the name or email address of the recipient. When you start writing, Outlook offers you matching suggestions. To browse the suggestions, press the Down arrow key. If you find the right persons among the suggestions, press Enter to add them to the To field.
Press the Down arrow key until you hear "Browse cloud locations," and then press Enter. The focus is on your OneDrive Recent folder. To change to a different folder, press Shift+Tab until you hear "Select files from," and then use the Down and Up arrow keys to browse the folders. Press Enter to select.
3a8082e126