We are creating a web app to replace an old-school green-screen application. In the green-screen app, as the user presses the Insert key to switch between overtype and insert modes, the cursor changes to indicate which input mode the user is currently in. In IE (which is the official browser of the company), overtype mode also works, but there's no visual indication as to whether overtype mode is on or not, until the user starts typing and possibly over-writes existing information unexpectedly. I'd like to put some sort of visual indicator on the screen if in overtype mode.
How can you determine if the browser is in 'overtype mode' from Javascript?
Is there some property or function i can query to determine if the browser is in overtype mode? Even an IE-specific solution would be helpful, since our corporate policy dictates the browser to use as IE7 (pure torture, btw).
(I do know that one solution is to do check for key presses of the Insert key. However, it's a solution that I'd prefer to avoid since that method seems a bit flaky & error-prone because I can't guarantee what mode the user would be in BEFORE he/she hits my page. )
The reasoning behind this question:
The functionality of this portion of the green-screen app is such that the user can select from a list of 'preformatted bodies of text'.
crude eg.
The excess for this policy is: $xxxxxx and max limit is:$xxxxxx
Date of policy is: xx/xx/xxxx and expires : xx/xx/xxxx
Some other irrelevant text
After selecting this 'preformatted text', the user would then use overtype to replace the x's with actual values, without disturbing the alignment of the rest of the text.
(To be clear, they can still edit any part of the 'preformatted text' if they so wished. It's just that usually, they just wish to replace specific portions of the text. Keeping the alignment is important since these sections of text can end up on printed documents.)
Of course, the same effect can be achieved by just selecting the x's to replace first, but it would be helpful (with respect to easing the transition to the web app) to allow old methods of doing things to continue to work, while still allowing 'web methods' to be used by the more tech-savvy users.
Essentially, we're trying to make the initial transition from the green-screen app to the web app be as seemless as possible to minimise the resistance from the long-time green-screeners.
In IE you can use document.queryCommandValue("OverWrite").
For IE only:
function isOverwriteEnabled() {
try {
// try the MSIE way
return document.queryCommandValue("OverWrite");
} catch (ex) {
// not MSIE => not supported
return false;
}
}
Firefox, Chrome, and Safari:
Because Mac does not have nor support the "insert" key, Safari will never ever support "insert" mode.
For Chrome and Firefox, "insert" mode is not encouraged for support as Mac does not have it. (Also, see "Furthermore")
That also means, since Windows supports "insert" mode, that IE will more than likely always support it.
Furthermore:
Firefox has a bug report classified as "WontFix" for years, so the "Insert" key will probably never be supported.
The problem is that if the user presses the insert key after entering your page then you can track down it easily.
But when the user has already pressed the insert key before entering your page then it seems to be a difficult task.
I suggest careful consideration of the 'overtype' feature. Does this behavior make sense in the web context, at all?
What utility does the 'overtype' feature provides in the old ANSI presentation which is unavailable through the web?
Unless I'm fully misunderstanding your question (apologies if so), I feel like the development intent may not align well with user expectations and typical web conventions.
If the goal is to produce a page where:
by default 'insert' mode is disabled
user can trigger 'insert mode' for editing purposes
...then why not use dynamic form inputs?
When a user clicks on a particular segment of HTML, a JavaScript is used to present the content as an element whose default value matches the chosen HTML tag.
Once editing is completed the input is parsed, the page updated, and form input removed from display.
Would this method suit your needs?
Related
I am trying to use accessibility features in RN and have few questions. How would I get rid of green box in UI, without disabling TalkBack. And the second is - how to enforce the order in which screen reader reads through the elements of view that is composed from several components? At the moment I manipulate state depending on certain parameters and pass it to attributes: accessibilityLabel, accessibilityHint, importantForAccessibility to accomplish that. Is there a better way to do it?
Here is an example:
this.setState(function(){
if(<some condition>){
return{
accessibilityLabel: "press right to move to other item",
importantForAccessibility: "yes"
}
}else{
return {
accessibilityLabel: "something else",
importantForAccessibility: "no-hide-descendants"
}
}
)}
and then
render(){
return(
<View
accessibilityLabel=
{this.state.accessibilityLabel}
importantForAccessibility=
{this.state.importantForAccessibility}
/>
)
}
How would I get rid of green box in UI, without disabling TalkBack.
The green box is part of Talkback. It's an important feature which makes it clear where the screen reader's cursor is; useful for a variety of disablities including partial sightedness, dyslexia, memory impairments, and attention difficulties.
As a user, it can't be turned off as far as I know. (I have Android Accessibility Suite version 7.2 on Android 8.0). Some screen readers on other platforms offer user preferences to customize the appearance though.
As a developer you can't turn it off either - it's part of Talkback, not the application. This is a good thing; it's the user's assistive technology, not the developer's. Even if a developer could turn off the screen reader's visual cursor, they shouldn't. (It would be like styling a web page with * { cursor: none !important; } - mouse users wouldn't thank you for that!)
how to enforce the order in which screen reader reads through the elements of view that is composed from several components?
When using web browsers, screen readers read web pages in the DOM order, so the general principle which applies to web pages is to make the visual order match the DOM order. (Aside: this is also important for sighted keyboard users, because a tabbing order which differs from the visual order can be very confusing.)
I'm not so familiar with React-native applications, but I would imagine a similar thing applies. You should structure the application's content and controls in a meaningful order. If the application has several regions, mark these up in a way that allows the user to skip to a particular region (with headings, ARIA landmark roles, or possibly other grouping containers). Be aware that screen reader users are not necessarily blind, so the point about visual order and DOM order is important.
It's worth clarifying whether you mean enforcing the "reading order" of the entire application (say, while a user explores the application UI just to see what's there); versus managing focus in response to a particular user action inside a particular widget (like a date picker). Since React-native uses JS, I'd recommend reading ARIA - Managing Focus to see if this applies to your situation.
Visitors on my page have the option to save their prefered settings as a cookie (I know some are against it, but this is not the point of this discussion).
If the user does not have a cookie, the user is asked if he/she wants to set up settings and then if yes redirect with javascript.
Can I detect non human trafic and not ask the "question" to them?
I have noticed google speed analytics are always beeing redirected to my settingspage which gives me wrong data in the analytics page.
So can I detect the non human trafic, by php or javascript?
EDIT: I would prefer to detect them in php as I have plans to phase out the javascript as much as possible
Use a honeypot - an empty, non-visible (but not hidden) field that bots will likely fill in. Also you can try and catch the click event, since bots like Google are not likely to emulate it crawling your page. Overall your best option though is using your .htaccess file (or robots.txt) to disable crawling of unwanted pages - check this out: Block all bots/crawlers/spiders for a special directory with htaccess
It is quite easy to do this, even so, there are many options, depending on your specific needs.
Here is a simple solution:
on each page, make the first link styled to be "invisible" (opacity:0), which points to some place that either triggers some javascript, or points to some place you want for robots; also place it off-screen (top:-999px)
set a timeout (like 500ms) on page load to give a robot some time to "click" the link
after the timeout, it should be a human user -if the "trap" was not triggered
optionally you can also check for mouse activity, but the above should suffice
This should work well, because a "human user" cannot click the link, but a bot can because it reads the HTML. Beware not to: "display:none", else the bot may skip this.
I'd recommend using honeypots to detect them.
Here's an interesting Article about this.
I don't know that Scroll Wheel is the right name for what I want, but I'll try to explain it.
On my I phone there are text boxes I can click on. Once you click on that box, you are presented with a scrollable list of items, for example numbers 1-10.
When you choose the number 1-10, either that value is placed in the text box and the list view is closed or you can "submit" that choice.
Is it possible to replicate this scrolling list of preset values in bootstrap? Ideally I want to have a list of times to choose from (1:00-1:30, 1:30-2:00) that an end user can scroll through on their phone and make a decision.
The answer to your question
Like others have mentioned in the comments, this is just how iOS renders <select> elements. Different browsers will render this differently, i.e. Android browsers come up with a slightly more conventional list, and desktop browsers will render it as a standard drop down list (albeit styled to fit with their UI, which can be frustrating).
Other things to be aware of
Bear in mind that if you try and override the default select elements with a plugin such as Chosen you will lose the various browsers default rendering of these elements, which can be one hell of a headache. There is also currently no easy way to detect whether your browser will render a select in a special way (such as the iOS style spinner) or use a dropdown, so its not like you can use something like Modernizr to apply your select plugin only when you're not using iOS/Android. If you want to do that you're in the murky world of user agent sniffing. (If anyone wants to correct me on this please do!)
Further reading
As a bit of an aside make sure you check out the new HTML5 input types. These provide things like native datepickers with no need for plugins (if the browser supports it) and many other types that have varying degrees of usefulness. For example, the type="tel" input is a nice one, that will render a normal text box in most desktop browsers, but on most phones/tablets/devices with virtual keyboards it will bring up a dial pad style keyboard, making it much easier for the suer to type in a phone number and giving them a strong indication of what you want. Just something that is very much worth thinking about if you are making forms for mobile and desktop, as it can make the mobile experience much more fluid. Browsers that don't support these elements will continue to render as they normally do as well, which is doubly nice. You can also use the likes of Modernizr to detect whether any of these input types are available to you, and do things differently. For example we have used Modernizr to detect if there is a native datepicker available, if there is, we just leave our <input type="datepicker/> alone, but if there is no datapicker we load in the jQuery datepicker, therefore making sure everyone has a datepicker.
This might be all obvious stuff to some of you but since this question had been pretty much answered in the comments I thought it would be useful to include some extra information about input types and different browsers rendering. If anyone wants to expand on my answer or correct anything (I'll be the first to admit to not being a complete expert on these things) please feel free.
I want to make my application accessible.
my application want to behave differently while screen reader is on and off
for example : http://jsbin.com/pakiwuqa/6/edit
when screen-reader(jaws) is on #textContent should be in tabbing after #btn1 or #btn2,
when screen-reader(jaws) is off #textContent should not be in tabbing
is it possible to test that jaws is on or off using javascript ?
I think you misunderstand how a screen reader (SR) is supposed to work, you don't need to put #textContent in the tabbing order.
If the SR user is browsing, they will likely read by using the arrow keys, and they will read through all the non-hidden content in source-code order (#textContent, item 1, item 2). This is standard behaviour and useful, if it could not read the content apart from things you can tab to, it wouldn't be much of a reader.
The role=application is oddly placed though, as that div does not contain any form controls, and might prevent some screen readers from reading #textContent. Application is a region, and should wrap a set of form controls or interactive widgets. When inside a container marked as application, the page is supposed to handle key presses.
If the user is filling in a form, the SR will behave more how you are expecting, and they will skip the #textContent unless it is marked up as a <label>, you use aria-describedby, or they use the arrow keys.
Lastly, there isn't a reliable way of detecting assistive technology on the web, and there are privacy concerns with that approach. It may never be possible, plus when you factor in not everybody who has a disability uses a SR, you find you're better off building an accessible page/application versus hack.
Background
I'm using POST form submissions instead of links with concatenated arguments inside a Web application, so I can exercise control over input.
Unfortunately this means users can't use the quick shortcuts they know to open links in new windows, like control-clicking or middle-clicking.
Problem
I've got what seems to be a workable way to use jQuery to capture mouse input and the various chord keys, based on the W3C DOM mouse events specification:
$("span#clickspan").click( function(event) {
buttonpress = event.button;
ctrlpress = event.ctrlKey;
$("#clickresult").empty();
$("#clickresult").append("<p>Click!</p>");
$("#clickresult").append("<p>Button # " + buttonpress + " pressed!</p>");
if (ctrlpress) {
$("#clickresult").append("<p>Control-click!</p>");
}
//form submission code would go here
event.preventDefault();
}
);
I can capture control-clicks this way (tested in Firefox 3 and IE7), and it correctly (?) reports left-clicks as coming from mouse button #0, but for some reason this code still isn't capturing middle-clicks on the span, and right-clicks still pop up the context menu. I'd like to capture middle-clicks, at least.
Can somebody help there?
What "control" means
The problem with a GET submission/link with concatenated arguments is that anybody can edit the address bar and type in anything. I've already worried about authentication and validation server-side. That's not why I want to work with POST.
I should only be showing users information that's meaningful. Internal database IDs aren't. I should only be letting users interact with the application in meaningful ways. Arbitrarily editing the address bar isn't one of those.
People make typos all the time. From the system's perspective, though, there's no difference between a typo in the address bar and a flaw in the application logic, and I'd rather not push the responsibility for deciding which one just happened off onto the users.
Short answer? Can't do it.
Long answer? Javascript mouse events. Still can't do it.
This begs the question: do you need to use POST or do you simply want to? The only reason why you'd need to is query string length. As to wanting to, you mention "controlling user input". What does that mean exactly?
You should never ever ever rely on the browser for input validation. You can do it there as a convenience but the server should always validate input.
Or is the reason aesthetic (ie shorter, "nicer" URLs)?
You're reinventing the wheel that is hyperlinks. I'm just trying to make sure you have a pretty darn good reason for doing so because it's counterproductive and you're never going to get the same browser support and compatibility as actual hyperlinks. Plus you're likely to simply annoy your users by having things they expect to work not work. Not good.