I am trying to automate the process of turning display layers on and off in a modeling program using AutoIt. I am currently using code that simply simulates a mouse-click at a particular pixel position and as that of course needs to be set up differently depending on the screen being used at the time, I would like to replace the mouse-click simulation with getting the information from the window, looking for a certain text, then checking or unchecking the "Map" and "Legend" check boxes.
My problem is that I don't know how to do that. If someone has a good way to include or point to screen shots let me know but until then I will try to describe everything the best that I can.
The window:
The window I am referring to is titled "Map Layers". The area that I am specifically interested is looks like a large list box (it takes up the vast majority of the window space) and it has 4 columns: Layer Name, Map, Legend, and Sample. Name has the name of the layer, Map has a check box to control which layers are displayed, Legend has a check box that controls which layers appear in the legend window, and Sample for some layers has the symbol that will appear in the legend. for my purpose the Sample column is irrelevant.
AutoIt v3 Window Info:
When I use the finder tool I can't get it to highlight the "list box" area, only the surrounding boarder that it and some buttons are in. The window info says that this surrounding boarder area (which seems similar to a panel) has a class of Button.
So my fundamental question is what code to use to drill into that "Button", find out what the list view looking thing is, and get the info from it, then interact with the map and legend check boxes without referring to pixel location (or at least grammatically get the pixel position).
If I have left out any important information or was unclear anywhere please let me know.
Edit: Forgot to mention and don't know if it helps but the info given using the finder tool for the column headers is Control: Class: SysHeader32
Try RanorexSpy and see if it can give you more details.
Related
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)
Is there a way to add a hidden info-text in FontForge? I think, I could need that sometimes.
I mean something like that:
Hint 1: I generate that text with a external graphic programm, not with FontForge itself; because that's my question how to do that.
Hint 2: The info text should be for own work, not for read out etc.
Hint 3: I mean info-text in the displayed area, not the comment function under 'glyph info'.
As a FontForge developer, I guess the best way is to make a point with a really long name. A single floating point shouldn't mess anything up, especially if it's inside the bounds of the left and right bearings of the glyph.
So, go to «Point→Name Point». If you want multiline input, copy and paste from e.g. Notepad++.
I noticed that it seems to render multiple lines in the wrong place, which seems to be a minor bug (I'll open a bug for it done: №4420), but you can just move the point up, or use multiple points floating at the right side for multiple lines.
I didn't see anything here or in http://shiny.rstudio.com/reference/shiny that seems to hit on this problem.
In an R Shiny tabPanel output, the sorting arrows align with the right side of the search fields at the bottom of the page.
Here's a pretty good example:
http://shiny.rstudio.com/gallery/datatables-options.html
Is there a way to make them align just to the right of the column name text up top?
Alternatively (or possibly both), is there a way to change the color of the arrows?
The default greyish doesn't really stand out. Bonus points to make the up and down arrows different colors.
Doing it directly in RShiny is best, but I could muddle my way through .js or .css if needed.
I'm trying to head off imminent support requests of "the column is sorting wrong" and "I can't see the arrows" before I push into production.
At the bottom of that shiny example you showed they show that you can pass in through the options parameter options to the rendering for the DataTable table, via the shiny::renderDataTable() function.
Hopefully the http://datatables.net/ site has documentation on what you want if it's indeed possible
If you look at Developer Tools on the http://shiny.rstudio.com/gallery/datatables-options.html page maybe you can see what element would need to be changed.
I am trying to code an app in Qt for capturing and then sharing the screenshots. For now my application captures the screenshot, shows a preview and saves it. I am yet to do the upload part. but before that I would like to be able to select the area of the screen of which the screenshot needs to be captured.
I tried searching and I couldn't find any helpful articles or documents in Qt. So can anyone help me?
PS: The idea is to create a similar app like lightshot and several other similar tools.
Thanks in advance
There are two methods that you can use for this: -
1) Capture an image of the screen and then display that, full screen to the user, essentially allowing the user to crop the image.
2) A more commonly used method is to create a full-screen, topmost window that has no title bar and is transparent. This allows the user to drag out an area, which you can draw an outline to represent the area the user requires.
I recommend the 2nd method and creating a transparent window is simply a matter of changing the window flags, as you can see here.
Take this text for example.
I would like to be able to display something like the text above, and let the user mouse over "text" and "example" to get two different ToolTip messages (lets say, "text: noun...definition: ...", and "example: noun...definition" respectively).
In this case, the text is static, so one option would be to put 4 different labels next to each other and style them differently. This might work in most cases, but i also need the text to word-wrap which wouldn't work with individual labels.
Can anyone recommend a solution for this?
It doesn't seem to get much love in our community, but you'll want to look at the TLF Engine. Specifically a TextFlow which has said "primitive" events (eg mouse__, roll__) for links. Style the link appropriately, and in theory you should be close to being done. Since this isn't a Flex-SDK baked-in component, it won't handle the toolTip for you, but it's easy enough to replicate. Create a new ToolTip manually - and add it to the PopUpManager.
http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e1126951a2d98-7ffc.html