When watching youtube videos, left/right arrows are used to jump back/forth several seconds.
How do I do this with vimperator?
(Oh my bad, is this question too short?)
Note that even with vimperator enabled, if you have flash player in focus, vimperator will not be able to interfere with the player's hot keys. That being said, if you are using flash player on youtube, then for as long as it is in focus, left and right keys will work whether vimperator is running or not.
Personally for me if the player is not in focus, arrow keys do not jump back/forth several seconds even without vimperator. However, if they used to for you, may be because you are using the HTML5 player (or in general, if you need to enable site-specific hot keys on any other website) this is how you do it:
If you just want to enable them temporarily once, just press the INSERT button. The text in the status line should change to IGNORE ALL KEYS, in which case vimperator will not interfere with any site-specific hot keys. Pressing INSERT again will get back to vimperator normal mode.
If you want to make certain websites to permanently ignore vimperator (for instance, I use OneNote online, which is not very vimperator-friendly), then add lines similar to these to your .vimperatorrc (on linux it's in your home folder)
autocmd LocationChange .* js modes.passAllKeys = false
autocmd LocationChange onedrive\\.live\\.com js modes.passAllKeys = true
Replace onedrive url wiht the youtube or the URL of any other website on which you want vimperator to disable itself.
Related
I am trying to select a dynamic calendar on a website. My goal is to open the calendar and input dates as I need to. I am not able to open the calendar by "Press button on web page" or "Click link on web page" with my selected UI Element. There are no ID's available to select. I have tried using the div class names with no luck. I have tried altering the selector to make a custom selector that looks for div names containing part of the class name. The 'Name' attribute in Power Automate is unavailable for the UI Element.
After trying all this, I noticed an Icon that is part of a div for the calendar, has
aria-hidden="true"'. When I checked the MDN here it has a warning statement: "Warning: Do not use aria-hidden="true" on focusable elements."
With being unable to select the calendar with standard and custom selectors, am I being blocked by the accessibility setting? Is Power Automate unable to focus on the calendar opener from aria-hidden="true"?
I don't know power automate, but what you observe makes sense. The attribute aria-hidden=true tells assistive tools such as screen readers and voice control software to ignore the element, as if it wasn't present at all.
A focusable element must never be aria-hidden=true. A screen reader won't know what to say when landing on it, and, as observed, it won't be reachable using voice control.
That's simply a pure accessibility fail (I would even call it stupidity, but well).
Technically, the solution is very simple: remove that stupid offending aria-hidden=true. Those who made that calendar probably put it there because:
they thought that screen reader and voice control users will always enter a date by hand and won't ever use the date picker
the date picker hasn't been made accessible, and so it's better to ignore it completely rather to present something only partially accessible
They copy/paste the code from elsewhere and didn't pay attention
They have no excuse for the third one, and for the two first, both reasoning are just wrong. Even if it isn't perfect, it's better to have a little something rather than nothing.
Keyboard-only user or screen reader user don't necessarily mean eased to enter a date manually. ON a mobile, the virtual keyboard is often painful to use, and people with limited movement sometimes use a device with only a few available keys (such as enter, tab, escape, and arrow keys only). Additionally, both might be combined if you think about someone who has a strong dyslexia and an inability to use his hands (the device would be actioned with feet, blinking eyes, etc.).
In theory, you shouldn't ever use custom widgets if you can avoid it. For entering dates, the standard exists: input type=date and friends.
Using standard widgets is the best guaranty to have something accessible at long term. Even if it might not be 100% accessible right now, it's getting better as the time passes.
Sadly, UX designers often don't like standard widgets much because it doesn't look like what they want, and there are still a few older browsers which don't support them all very well.
We have a web-based app which uses a side-by-side experience for desktop users where the left side of the screen is a file browser and editor and the right side of the screen is an interactive preview. Users of our app will make constant and iterative changes on the left and and then interact with the preview on the right, switching back and forth many times in quick succession.
Is there a "best practice" for allowing quick and easy navigation between these two interactive areas? I know this might fall under the "opinion" category, but I feel that accessibility is such an overlooked topic that it helps to have as many resources as possible.
You have a few tools at your disposal.
Headings
Headings are one of the easiest ways to bake in some super simple section switching. Screen reader users will use the keys 1 through 6 to navigate by heading levels so if both of your panels are <h2>s (for example) they can simply cycle location using headings.
Keyboard shortcut keys
You can set keyboard shortcut keys.
However you should never do this in isolation. By this I mean if you say that switching window is say Alt + 0 you must allow users to be able to change these key bindings to their preferences.
This is so your shortcut keys don't interfere with their screen reader keys (as they may have set custom keyboard shortcuts).
please note: as pointed out in the comments this is not a WCAG requirement for key combinations (which is only for single keys) but is a usability best practice and highly encouraged, especially as some screen reader users use a modifier key rather than a toggle key for screen reader navigation.
Then we get into an interesting area which I like to illustrate by saying "how would a one handed user use your page?".
This example makes you realise that some sort of sticky keys solution may also be considered where key combinations can be done with a sequence of keys, any time apart (as you may have someone with NO HANDS using eye gaze technology or a switch for example so you don't want to impose a time limit.)
Obviously the above are extreme examples but things you may want to consider (and in reality anyone using eye gaze would be able to visually switch panels etc.)
Voice commands
Being able to switch panels via voice (for example Dragon Naturally Speaking) is also essential.
Now you can do key combinations with voice software so that fixes most issues but they can be annoying and fiddly.
One thing that is quick to use on most voice software is clicking any button on a page with a unique name.
As such having a button above each panel that activates it would be beneficial to voice users.
Assuming these buttons have unique names I could simply say "click activate panel 2" (where "activate panel 2" is the button name) and switch immediately.
Do you need to manage focus?
Bear in mind that when you switch panels you will by default start at the top each time.
This may be exactly what you want but more than likely this would be a terrible user experience.
Instead you may want to remember the previous focus location. Then if I use the keyboard shortcut it would jump back to the same location in the panel. If I use the voice / button click to change location same again.
However if someone uses headings to navigate this obviously wouldn't work. You could then give them a button directly after the heading that says "resume from previous location" to fix this and use that to manage focus.
User settings
As you can see there are loads of things that different people with different requirements may or may not need.
As such adding all of the features by default would probably make the application worse to use for majority of users.
Instead have a settings screen that lets a user turn on features that benefit them, set their own shortcut keys, turn on or off sticky keys, decide if they want you to manage focus for them (or not) etc.
This is a difficult problem! I have been giving a similar issue a lot of thought. I have outlined one idea that uses ARIA live regions, and an alternative idea that might work better if quick-jump keyboard support is vital.
Live region announcements as part of a <form>
The <output> tag may be what you're looking for. It is mapped to the ARIA role of status so any changes to its content will be announced without any focus change. That way, the user can continue to navigate and make changes on the left side without always having to flip over to the right side to know what changes were made.
The role status has an implicit aria-live value of "polite", so that the announcement will wait until any other descriptive announcement is finished.
It has an implicit aria-atomic value of "true", which means that any change will trigger the announcement of the entire contents of the element -- which may or may not be appropriate for the content. If not, add aria-atomic="false" to read out only the changed node.
If the content inside the <output> could be anything other than phrasing content (including <div>s or heading tags) then you should use a <div> with the role attribute of "status" instead.
Custom keyboard controls can get tricky with various types of assistive technology (AT) software/hardware. Plus those commands probably can't be made easily discoverable. Some ATs provide a keyboard command to flip between a controlling element and the element assigned via its aria-controls attribute. Unfortunately, this functionality is poorly supported, but it is the current standard, so support may get better over time. Currently only NVDA on Windows supports it, with the keyboard command Insert + Alt + M.
Adding aria-controls to an element controlling an <output>/status is mandatory anyway, so give it a unique id attribute and set that as the value of aria-controls on each form element inside the <form>.
If the <output>/status is wrapped in a <fieldset> and the inputs are all wrapped in a containing <fieldset>, then each <fieldset> acts as a grouping container, so the user can navigate between them quickly. As part of this, ensure the <fieldset> containing the <output> directly follows <fieldset> containing the form elements in the source order. If this isn't possible, add the aria-owns attribute to the containing <form> and reference the id attributes of both <fieldset>s with a space in between.
Always-open non-modal <dialog>
You may instead consider making the right side pane an always-open non-modal <dialog>. A <button> next to each interactive element on the left pane would move focus to the <dialog>, and the Escape key would return focus back to the <button>. Focus isn't trapped within a non-modal <dialog>, so the user can still move between each pane using normal navigation methods. The <dialog> needs to have an open attribute to appear and it also needs to have aria-modal="false".
Each <button> would need an aria-controls value referencing the <dialog>'s id attribute, and an aria-haspopup value of "dialog". The <button>s could be invisible until focused.
There's only a single focused point at any given time. So there isn't any real miracle solution, screen reader and other keyboard-only users will necessarily have to repeatedly go back and forth.
IN fact, the most important isn't to be able to switch quickly between the different parts (you must only somehow give a way to do it only with keyboard), but to not lose cursor position when you switch.
For example if I edit something on the left, go to the right to check the result, and then go back to the left side, I expect to find the insertion point exactly where I left it off.
You really have to make sure that this is always correct, and as closest as possible when changes occurs (especially when it's asynchronous, i.e. a change occurs on the right side when you are on the left side).
The most similar accessibility recipe or component is probably split view.
In windows world, the most used shortcuts for cycling between the different splitte parts is F6, and Shift+F6 to cycle in reverse direction.
Don't hesitate to add other easier or additional shortcuts if the switch has to be really frequent, such as Ctrl+Tab, if such shortcuts aren't already used for something else.
F6 and Shift+F6 aren't the easiest shortcuts to perform, especially on laptops where all F1-12 keys may not be available at all or only by using an additional FN key. I personally always found F6 a questionnable choice, but that's only an opinion; at least we have something and that's of course better than nothing.
However, don't replace an existing shortcut commonly used. (for example Ctrl+Tab = switch between different tabs, don't use it for cycling between views if there are tabs in your application and keep it for the tabs)
I'm writing a Firefox (web)extension. I have a browser_action in my manifest.json, with a default_popup. I want my extension to be accessible by all users, including those with vision impairment.
So I'd like to, as I change and develop things, test what it's like to (for example) interact with this feature, using only the keyboard. How do I do this? How do I focus and thus "click" the toolbar button, without a mouse?
Ideally, without actually running special screen reader software every time.
So I'd like to, as I change and develop things, test what it's like to
(for example) interact with this feature, using only the keyboard. How
do I do this? How do I focus and thus "click" the toolbar button,
without a mouse?
You can use commands to set a keyboard shortcut.
_execute_browser_action: works like a click on the extension's browser action
You may also add commands.update() (Firefox 60+) API to let users change that keyboard shortcut.
Thanks for considering accessibility. Just to clarify, because I don't think you meant this, but you can do keyboard testing without a screen reader. Just don't use your mouse :-) Seriously.
In my current firefox, I have an address bar, the search field, then a bunch of plugins on a toolbar.
On a PC (should be similar for a Mac, but Cmd instead of Ctrl):
I can move my keyboard focus to the address bar with alt+d or ctrl+L (cmd+L)
I can move my keyboard focus to the search field with ctrl+k (cmd+k)
Interestingly enough, I could not get my focus on the toolbar. I could have sworn I could tab from the address field, to the search field, to the toolbar, but it's not working now.
If you can get your focus there, then you should be able to use the left/right arrows to move between tools and then space/enter to select the tool.
If you want to play with a screen reader, NVDA is free.
I'm 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.
You can't and you shouldn't. Different verbosity settings like functional keys announcement, punctuation reading, repeated characters announcement, treatment of dialog controls and so on, and so forth, — all of these are entirely up to the screen reader and the user who adjusts these settings. Just like, for example, speech rate or pitch. As a JAWS user, I wouldn't be happy, and more than that, I would be angry if some app developer forced me to turn off my Tab announcement or changed my punctuation level.
Update: If you just want to turn off keystrokes announcement for yourself, do the following:
Press Insert+6 on the number row to go to JAWS Settings Center. You can do this from the JAWS main menu, but the single keystroke is much faster.
If you want to make your change by default for all apps, press Ctrl+Shift+D to open the default file.
In the search box type labels and search for Key Labels.
In the dialog that appears turn off the announcement for all of the keystrokes you don't want to hear. Note that if you mute Tab, all of the keystrokes like Shift+Tab and Ctrl+Tab will be muted automagically.
click OK several times to leave Settings Center and save your settings.
It's just a user setting options.
If you do that in your jaws, it's coild bé different for an other person !
This site is claiming to prevent the download of images and preventing screenshots. Is this truly possible to stop and can anyone crack it in their demos? What tools can be used to download an image set as a background?
http://www.iptlock.com/how.php
It isn't possible, no.
If the client can see it on their screen, then it exists on their computer. Even if that weren't the case, there is always the whole analog thing (people can literally take a picture of their screen).
If you have chrome: Just go to one of their demos, press ctrl+shift+c, and an inspector will show up, showing you all individual parts of the page. Then select the image from the list (servedemoimg) , right mouse click on it, and you can save the jpg. It is not possible to prevent people from downloading those files. And this company doesn't even make it particularly difficult.
Their scheme "works" by hiding the content whenever a key is pressed or the main window loses focus. They also attempt to detect that something has been copied to the clipboard and they replace it with some text ("It is prohibited to copy distribute or in any way alter these copyrighted images").
That means that if you press any key to copy the content, you'll just get the "locked" graphic. The same goes for switching to another app (like a screen capture app) because the screen capture app will have focus instead of the browser, causing the lock graphic to show. If you do manage to copy something to the clipboard, it immediately replaces the content with the text I mentined above.
Furthermore, their content is a background image so you can't easily print or right-click to copy the image by disabling JS.
However, it's pretty trivial to defeat. My first attempt using IE8 was trivial. When I went to the "protected" page, IE asked me if I wanted to allow the page to access the clipboard, and I clicked "Don't Allow". Then I pressed PrntScr and was able to paste the content into another program. This worked because that particular key isn't captured by the browser and I didn't allow the page to see my clipboard.
Then I tried again, this time allowing clipboard access. This time I used a screen capture program that automatically captures the foreground window after a set time delay. This worked because I was able to give the browser window focus, and the screen capture utility just saved the image as a file instead of putting it on the clipboard.
Lastly, I just saved the source as a file and saw background:url(servedemoimg.php?filename=IPTbusiness_graphicdesign_ITB). Just putting http://www.iptlock.com/servedemoimg.php?filename=IPTbusiness_lawyer_ITB into my browser's address bar made the complete "protected" content show up for me to download, print, email, etc.