Hide textfield blinking cursor - html

I have a textfield is there a way to hide the blinking text cursor? I say this because I am doing a horror/mystery website and one of the clues is to start typing anywhere.
Maybe I can do it with javascript?

The basic idea is, that the cursor's color is the same as the text's color. So the first thing you do is make the text transparent, thus taking the cursor away with it. Then you can make the text visible again with a text shadow.
Use this link to see it live in jsfiddle.
input[type="text"]{
color : transparent;
text-shadow : 0 0 0 #000;
}
input[type="text"]:focus{
outline : none;
}
Update:
Known to not work in iOS 8 and IE 11
Another idea of my is a bit more hacky and requires javascript.
HTML and CSS part:
You make 2 input fields and position one exactly on top of the another with z-index, etc. Then you make the top input field completely transparent, no focus, no color, and alike.
You need to set the visible, lower input to disabled, so that it only shows the content of the above input, but not actually works.
Javascript part:
After all the above you sync the two inputs. On keypress or on change you copy the contents of the higher input to the lower.
Summing all the above: you type in an invisible input, and that will be sent to the backend when the form submitted, but every update of the text in it will be echoed into the lower visible, but disabled input field.

caret-color: transparent !important; works in newer browsers

Try this:
$(document).ready(
function() {
$("textarea").addClass("-real-textarea");
$(".textarea-wrapper").append("<textarea class=\"hidden\"></textarea>");
$(".textarea-wrapper textarea.hidden").keyup(
function() {
$(".textarea-wrapper textarea.-real-textarea").val($(this).val());
}
);
$(".textarea-wrapper textarea.-real-textarea").focus(
function() {
$(this).parent().find("textarea.hidden").focus();
}
);
}
);
.textarea-wrapper {
position: relative;
}
.textarea-wrapper textarea {
background-color: white;
}
.textarea-wrapper,
.textarea-wrapper textarea {
width: 500px;
height: 500px;
}
.textarea-wrapper textarea.hidden {
color: white;
opacity: 0.00;
filter: alpha(opacity=00);
position: absolute;
top: 0px;
left: 0px;
}
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<div class="textarea-wrapper">
<textarea></textarea>
</div>
The idea is to create a second, invisible <textarea> over/on-top-of the real one. The user is typing in the invisible one but the text doesn't appear (nor the caret/cursor) as it is invisible! You then use JavaScript to assign its value to the visible one.
But it doesn't seem to work in IE8 :'( the caret is still visible even though the opacity is cranked up to 11.
But it works in Firefox... ?

I was looking for a way to hide the blinking cursor on iOS devices for date inputs that trigger a calendar, because you could see the cursor blinking on top of the calendar picker.
input:focus { text-indent: -9999em; }
So in this case my CSS works nicely, obviously the downside is that if you need to see what you are typing then it is not good

I think this is a perfect solution:
make the input wide enough, align right to screen right, thus make cursor and content locate at the outside of the screen, while it's still clickable

Unfortunately you can not style the text cursor with CSS. You can only do some very bad JavaScript tricks but depending on the layout and requirements of your website, it might not be possible at all. So I would recommend to forget the whole idea.

<input style="position: fixed; top: -1000px">
Works in iOS8.

you can "Hide textfield blinking cursor" by calling blur function on focus event
<input type="text" onfocus="this.blur()"/>

function noCursor(a){
var a = document.getElementById(a),
b = document.createElement('input');
b.setAttribute("style","position: absolute; right: 101%;");
a.parentNode.insertBefore(b, a);
if(a.addEventListener){
b.addEventListener("input",function(){a.value = b.value});
a.addEventListener("focus",function(){b.focus()});
}else{
a.attachEvent("onfocus",function(){b.focus()});
b.attachEvent("onpropertychange",function(){a.value = b.value});
};
}
noCursor('inp');
<input id="inp">
You can use the function for each element jou want no cursor for.

Setting the input to readonly also does this since it prevents focus but it may not be applicable to many use cases that still need it.
<input type="text" readonly />

List of recommended css solutions to hide the caret
caret-color: transparent; - For my case this approach wasn't good enough since you're still able to manipulate the input field in order to show the caret on ios. You can reproduce it on an ipad by focusing on an input then press the keyboard button that brings the keyboard down. After that you can simply just click on the input field again and suddenly the caret appears. I have also been able to see the cursor on iphones but i'm not exactly sure how to reproduce it since it seems kind of random.
opacity: 0 - This approach does not work on android devices since you won't be able to focus on the input. Another thing I don't like is the fact that the site wouldn't automatically scroll up/down to the input after focusing.
text-indent: -9999em; - This isn't really a solution in itself since the caret always would be in the left upper corner of the input, atleast on ios devices. Though if you set the width of the input to overflow the website's width then you wouldn't be able to see the caret.
visibility: hidden; display: none; - These solutions do remove the caret but you'll not be able to focus on the input, not even if you've implemented a click event to do it.
font-size: 0; - I do not recommend this approach since it doesn't work on adroid devices and apparently some windows computers. The browser will also zoom in on the input if the font-size is less than 16px therefore you would have to add maximum-scale=1 to the meta viewport tag. You would also have to display the input somewhere else than the input field.
What I did
I ended up not using any of these methods since they didn't work well for my project. I instead used a lightweight code editor like Lajos Mészáros also recommended and made the height of the input 0. That also means you'll need to make a click event on another element that sets the focus for the input. You can look at Monkeytype for reference (I'm not affiliated to that website).

just made a proof of concept for a friend of mine, using #sinfere 's idea:
demo: http://jsfiddle.net/jkrielaars/y64wjuhj/4/
The start of the input is offset so it falls outside of the container (which has overflow hidden)
The actual caracters (and blinking cursor) wil never enter into view.
The fake div is placed below the input field so a tap on the fake div will set focus on the invisible input.
<div class="container">
<div id="fake" class="fake">
<span class='star empty'></span>
<span class='star empty'></span>
<span class='star empty'></span>
<span class='star empty'></span>
</div>
<input type="text" id="password" class="invisible" maxlength="4">
</div>

Related

Make HTML form elements 'display only' - non-interactive

I'm working on a dynamic form builder, where the user can add different blocks of content to a page (buttons, text inputs, paragraphs of text, images etc), which they can later publish and it will be a simple HTML form they can use.
For the 'preview' section of this application (where they are adding different blocks of content and modifying the content and look of it), it occurs to me that the simplest way to do this, is to just display the end product HTML itself and that way I'm more or less guaranteed that what is displayed in the preview matches what is displayed in the actual form.
Where this is important is with obscure styling quirks, such as the behaviour of buttons with display:block.
However, I don't want the the preview to be actually interactive like the real form would. That is, I don't want the following behaviours:
Inputs receiving focus and being able to insert content
Buttons having click animations
Clicking links navigating
Default hover styles occuring.
Also, in terms of accessibility, it might be very confusing if there are a bunch of input that don't do anything appearing on the screen.
Is there a browser native/standard way to do this?
My fallback will likely be to disable all of the elements. But this won't work for links for example.
An alternative might be to put an invisible div on top of the form, which captures all of the click events. But I don't like this from an accessibility POV.
Is using the role="presentation" intended for this?
Code Example
As an example here, see some sample code here: https://codepen.io/dwjohnston/pen/qBrGPmr?editors=1111
Now for this, I have the divs with role="button" - These buttons are intended to be clickable, - when you click them the side panel will show content configuration eg, the default value of the input, label, etc.
Already, there is a problem - interactive content is not permitted inside a button.
But also, I shouldn't be able to tab to those controls, (now I can manually add tabindex = "-1", but that's not the complete picture). I don't want to confuse screen readers etc.
INFO
There is an edit to this question that addresses the specific issues OP has with their current implementation. I have left this first part here as my original answer.
I don't want the the preview to be actually interactive like the real form would.
Why? Having the form be interactive would be great for all users (taking into account that some functionality needs to not work fully in a preview).
Let people see what default hover styles look like, what clicking links would do (i.e. click the link and alert says "would navigate to xxx page") etc.
I understand not wanting to be able to navigate to new pages and submit the form (any "save" or "update" actions plus any "navigation" actions) but everything else I believe should be able to work in a preview.
Also, in terms of accessibility, it might be very confusing if there are a bunch of input that don't do anything appearing on the screen.
It would be far more confusing if a preview appeared on screen but then I couldn't navigate to the buttons, links etc.
How would that behave for a screen reader user? i.e. would you hide all elements using aria-hidden="true" (in which case how would they test the page?).
My fallback will likely be to disable all of the elements. But this won't work for links for example.
This is really one of the worst ways you could handle it, disabled inputs generally can't receive focus so keyboard users would suffer when testing.
Plus if some elements in the final production form are disabled until a certain field is filled in (for example) then how could a user test that in your end form?
Also if you intercept the navigation for a link without explaining why the link doesn't work that could also cause confusion. (and yet again could that link open in a new window in "preview" mode if you explain that to end users? Obviously depends if it is a static link etc. but just a thought on a way users can check any custom links point to the right place).
Proposed Solution
I would say you need two versions of the finished form. The "real world" one and the "preview" one.
The HTML can be (read "should be") identical but you need to implement JavaScript handlers to disable the functionality you don't want to be active.
There is nothing wrong with having an editing tool only work with JavaScript if that is one of your concerns, as long as you provide a warning to end users that the tool requires JavaScript to work. (The difference between a publishing tool and an end user experience is you can be much more reliant on JavaScript.)
For example: Let's say you have a <button> that when clicked should add a new row to the form (in the production version of the form) and for whatever reason you do not want this functionality to be active in the preview version.
In that case in the preview / demo version of the form when you click this button an alert could be shown that says "will add a new row to the form".
That way screen reader users and keyboard only users can test the form without you needing to do too much extra work (and can also see if the form has usability issues for keyboard users while they are at it!)
I think this would be the most clear for everybody and a much better user experience.
You just need to think of navigating in and out of preview mode (Esc to close for example) and quick edits (when you preview the form give the option to focus the previously focused element if the forms are particularly long, keyboard only users will thank you for this! The same for when you go back to the edit, put focus back on the last edited item).
Further reading
From an accessibility perspective WCAG isn't what you are looking for in this scenario, Authoring Tool Accessibility Guidelines (ATAG) is.
This is a little known set of guidance on how to create editors, WYSIWYGS etc. etc.
As with all W3C guidance it is a heavy read but if you understand the core principles it will guide you to good decisions and you can always ask here if you need clarity on some of the individual points that aren't clear :-).
EDIT: How could you achieve an accessible interface with the current design
The issues that you have within the codepen you linked and their solutions are as follows:
Stop interactive items receiving focus
As you wrap each element you have correctly diagnosed your biggest issue which is nested interactive elements.
The solution to this is quite straight forward: Give every interactive element a tabindex="-1" as you said. This makes sure they cannot be focused incorrectly.
Make sure the actual wrapper item can be focused and activated
Then we just need to make sure that the wrapper .content-item has tabindex="0" so it is added to the focus order.
We also need to capture the Enter and the Space keys and ensure our panel is activated with them also.
Visual focus indicator
I also added an outline to the wrapper "button" so that visual focus indicators are available.
So that essentially fixes normal keyboard navigation issues, the next issue is how a screen reader will interpret nested buttons, inputs etc.
Screen reader corrections
Here I would also go simple, hide the button, input etc. entirely from a screen reader and instead explain what element is inside.
Effectively we make the button invisible and instead describe the contents of the .content-item.
To hide the element we use aria-hidden="true"
To announce something meaningful we can use some visually-hidden (screen reader only) text inside a <span>. This will be far more robust that using aria-label with such a complex application.
make the application behave well with a mouse
Final challenge - stop mouse events.
Luckily pointer-events: none has really good support and even on the few browsers that don't support it being able to click into an input isn't the end of the world (we have fixed it for keyboard users)
Example with all issues resolved:
This solves all of the issues with your selection method.
Please note it doesn't take into account accessibility errors of the components themselves (for example the <input> having no <label> etc.) but I assume that is just because it is an example.
The only thing you need to work out is how to generate the visually hidden text describing the item and the .content-info "button" action.
document.addEventListener("DOMContentLoaded", function () {
const items = document.getElementsByClassName("content-item");
const rightPanel = document.getElementById('right-panel');
for (let i = 0; i< items.length; i++) {
const item = items[i];
item.addEventListener("click", (e) => {
console.log(e.target);
const id = e.target.dataset.id;
rightPanel.innerHTML = id;
});
// ADDED this to capture the Enter and Space presses on our wrapper button
item.addEventListener("keydown", function(e){
if(e.keyCode == "32" || e.keyCode == "13"){
console.log(e.target);
const id = e.target.dataset.id;
rightPanel.innerHTML = id;
}
});
}
});
.main {
display: flex;
flex-flow: row nowrap;
}
.left {
flex: 1 1 auto;
}
.right {
flex: 1 1 auto;
}
.content-item {
margin-top: 20px;
width: 600;
border: solid 2px blue;
cursor: pointer;
}
/* ADDED a focus indicator so keyboard users know where they are */
.content-item:focus{
outline: 4px solid #333;
}
/* ADDED to stop pointer events reaching the input, button etc. */
input, button{
pointer-events: none;
}
/* ADDED the visually hidden class so we can provide meaningful text to screen reader users */
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<div class ="main">
<div class ="left">
<!-- Added `tabindex="0"` so the wrapper is focusable by keyboard -->
<div class="content-item" role="button" data-id="item-1" tabindex="0">
<!-- added `aria-hidden="true"` and `tabindex="-1"` to hide the input from screen readers and make sure it cannot be focused by keyboard, I also added `role="presentation"` just for good measure, although it shouldn't be needed. -->
<input type="text" aria-hidden="true" tabindex="-1" role="presentation">
<!-- Added this span that explains the action that the "content-item button" would perform if clicked. You need to come up with something meaningful for the contents of this -->
<span class="visually-hidden">Edit input [input identifier]</span>
</div>
<div class="content-item" role="button" data-id="item-2" tabindex="0">
<button aria-hidden="true" tabindex="-1" `role="presentation"`> I am a button</button>
<span class="visually-hidden">Edit button [button identifier]</span>
</div>
</div>
<div class ="right" >
<h2> Right panel</h2>
<div id ="right-panel">
</div>
</div>
</div>
You might want to look into the inert attribute. It is not supported by any browser at the moment, but there are polyfill libraries.
The idea is that marking this on any element will make it and all its children non-interactive and invisible for accessibility purposes.
You can read some background and download the library here:
https://github.com/WICG/inert
Try this
$(document).ready(function(){
var demoPage = $('div.demoPage');
demoPage.find('a').attr('href','#');
demoPage.find('button').attr("disabled", true)
})
div {
padding: 20px;
margin: 20px;
background: #eee;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.4/jquery.min.js"></script>
<div class="no-copy">
<p>You can't click me.</p>
</div>
<div class="demoPage">
<a href="www.google.com" readonly="" class="no-copy">
It is a link
</a>
<button> It is a button</button>
</div>
<!--you can do this-->
<input type="text" id="input" disabled>
<script>
document.getElementById('input').disabled = true;
</script>
You can do that very simple by adding some css classes:
<div class="content-item disable-control" role="button" data-id="item-1">
<input type="text" />
</div>
<div class="content-item disable-control" role="button" data-id="item-2">
<button> I am a button</button>
</div>
^^ I added an additional "disable-control" class
.content-item.disable-control * {
pointer-events: none;
cursor: inherit;
user-select: none;
}
.content-item.disable-control *::selection {
background: transparent;
}
Make sure to add some browser-specifix css if needed, e.g.
*::-moz-selection
.. and of course, you can modify my code to apply the class only once (for the whole left pane) and not for each control seperately
Add the disabled attribute to all form elements that you want to disable.

CSS Change Color Of Focus Rectangle (Location Focus)

I have a textarea with transparent text. I need it to be transparent to work around a problem I'm having with Highlight.js.
It works fine, but there is a problem though. The user doesn't know where he is in the textarea. I need the focus rectangle (that's what it's called in the Windows UI apparently) to have specific properties. In this case it must be white and flickering. The rest of the text should stay transparent.
textarea {
color: transparent;
z-index: 1;
}
Like that, but with a white focus rectangle.
EDIT:
People seem to misunderstand me. I don't want to edit the cursor. I want the edit the vertical flickering dash that indicated where you're editing in the textarea.
EDIT2:
It's called a caret apparently.
Hey You can refer the following Blog for your requiremenr :
https://beradrian.wordpress.com/2008/01/08/cross-browser-custom-css-cursors/
Let me know if is it helpfull to you.
code:
input, textarea {
cursor: url(cursor.cur);
}

HTML input text box scrolls up and down if drag with mouse

I tried to replicate the problem I'm having on my website with the below js fiddle but couldn't.
http://jsfiddle.net/YD6PL/116/
HTML:
<input class="givenLetters" type="text" value="h" disabled>
CSS:
.givenLetters {
width: 40px;
height: 40px;
text-align:center;
font-style:italic;
font-weight:bold;
text-decoration:underline
}
For some reason on the website when the user clicks and holds the mouse button they can scroll the input text up and down. It would be like being able to drag the 'h' in the js fiddle example up and down but still within the textbox.
What could cause this behavior? I would like the website to function as the js fiddle but can't figure out what would be different with the website.
The box-sizing, display or line-height properties come to mind if you're getting scrollable text. Open up a web development console (Firebug in Firefox or CTRL+SHIFT+J in Chrome), use the element selector to choose the element and then start disabling properties until the effect stops. Keep in mind it could be a combination of properties as well.

How to get a screen reader to read a disabled element using aria?

I'm trying to get a screen reader to read the values of number spinners/ text boxes that have been disabled so that they are un-editable. The value of these boxes is important in context, but the screen reader (JAWS in this case) only reads the values of the widgets as 'unavailable'. I tried setting aria-required='true' to no such luck. Is there any other way to get a screen reader to say these values?
Ex:
<input id='exampleInput' disabled='true' aria-required='true'>1</input>
Using the Read-only attribute is the right option here.
if this will mess with you JavaScript then I suggest changing your JavaScript so that it will check for something other then the disabled attribute.
this can be done by using a Css Class, or by adding a new attribute, or you can add a new field to the DOM object and use that.
I encountered a similar problem recently, my solution was to use some informational text for all the disabled buttons, which is only viewable by screen readers. I used a button element so it still retains a place in the tab order, so if a screen reader user is tabbing through the form it will be announced, you need to implement some code to remove the elements from the DOM once the actual inputs are enabled.
The hidden element announces as “data value goes here element disabled” when tested with NVDA, you can use whatever text you want, obviously.
HTML
<input type="text" name="myDisabledElement" disabled="disabled">
<button aria-disabled=”true” class="sr-only">
data value goes here element disabled
</button>
CSS
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
You can see it in abstract action here: http://codepen.io/chris-hore/pen/LEKyeM

File upload button and odd text cursor behavior in IE

I've built an upload button that's formatted to look like your typical html button, instead of the browser standard file upload form. The approach was to style an anchor element and overlay a transparent file input element on top.
This approach works fine in all browsers but IE. In IE, when the user clicks the upload button a text cursor appears as if the user had clicked on a text input box. The user can trigger the file upload dialog by double clicking the button. But this isn't the behavior we want or that anyone expects.
I'm at a loss as to why this is happening. I've set up a jsfiddle demonstrating the issue here:
http://jsfiddle.net/davelee/yfSmc/3/
Meet this bug on IE11, fix it with font-size: 0;
I have just worked on this exact issue. With IE, yes, there is a small area on the left of the button that acts as a text input (for the file name to be entered manually). The solution that I figured out was to increase the font-size of the input field. Strange, I know, but by increasing the font-size, you increase the "Browse..." button portion of their input field, and therefore increase the clickable area and push out the text portion of their upload button. Since the button is transparent anyway, nobody is the wiser :)
Setting the width and height of the file input element fixes the issue in both ie8 and ie9.
http://jsfiddle.net/davelee/yfSmc/4/
Take a outer div to that input file apply over flow hidden and width to it, then to the input file apply some css like: font-size, margin-left in negative.
<div class="outerWrap">
<input type="file" id="fileUpload"/>
</div>
and the css will be:
.outerWrap {
width: 200px;
height: 50px;
overflow: hidden;
}
#fileUpload {
width: 210px;
height: 50px;
margin-left: -10px;
font-size: 70px;
}
adjust the width and margin-left according to your requirement.
for reference got this link: http://jsfiddle.net/TrdJ8/
and try it out on IE-9
try adding css
z-index
to your absolute elements.
lowest element
z-index:1
highest
z-index:2;
and set a z-index on the container element.