First of all I am disappointed that the plugin itself is only in English. If the user clicks the Apply with LinkedIn button and logs into a French profile, for example, it displays correctly. Only to return to a page with the plugin displaying "Already Applied" in English.
To get around this I wrote some javascript to replace the "Apply with LinkedIn" and "Share" text with French equivalents after the buttons load. The issue I now have is with the "Already Applied" version of the button. It appears that it loads asynchronously to the actual plugin meaning that it overrides my French text in some cases, but other cases it does not.
I know that I can harness the onsuccess event when an application is submitted. However when that LinkedIn user revisits the page the "Already Applied" text does not always appear in the correct language.
Question 1: Has anyone had luck with any techniques to achieve the desired results?
Question 2: When oh when will LinkedIn finally properly support this?
Any help or direction is much appreciated.
Thanks!
UPDATE:
I can confirm that Igor F.'s solution to use the setInterval function and check every 100ms for a change was the best option and worked flawlessly in all tested browsers.
Thanks for all the help and suggestions!
The plugin seems to receive its information asynchronously from the server and act upon it, i.e. change the content of the page. Have you tried listening to DOM mutation events?
Here is an example how they work when the user causes a change in the web page:
<html>
<!-- This is just mock-up to allow user to modify the DOM -->
<body>
Text to add: <input id="in1" type="text"/>
<button onclick="addNode();">Add node</button>
<p id="toAdd"></p>
</body>
<script type="text/javascript">
function addNode() { // adds a text node to the <p> element
document
.getElementById("toAdd")
.appendChild(document
.createTextNode(document
.getElementById("in1")
.value
)
);
}
///////////////////////////////////////
// Here comes the interesting part: !!!
document
.getElementById("toAdd") // listen to modifications of the <p> element
.addEventListener(
"DOMSubtreeModified", // in this case all modifications of its subtree
function() {
alert('Modified!'); // change this to whatever fits your purpose
}
);
</script>
</html>
More about mutation events here. If you want to support IE < 9, you'll need a different approach. Maybe periodically check, e.g. every 100 ms, whether the web page contains the English button and change it into French. See setInterval(). This should be future-proof (mutation events are deprecated), but probably even more inefficient (slow).
In any case, it's a hack. Only LinkedIn can provide a clean solution, e.g. allowing for a language code parameter for the plugin.
From what I gather, this is the problem you're seeing:
The button initially loads with the text "Already Applied".
You modify the button text to change the text to French.
LinkedIn modifies the button text to change it to "Already Applied".
...and it's intermittent because sometimes 3 happens before 2.
I can't think of a "good" solution to this problem, though I would like to hear if Igor's answer works. I can think of a good hack:
The asynchronous call must be targeting the button somehow, probably through its classname*. So after you've changed the text to French, change the classname to something else. This way the asynchronous call will fail, and your text will never be overridden.
The consequence is that LinkedIn will lose all access to this button, but since it's an Already Applied button, I don't think that will matter. You also risk losing CSS attributes selected using the classname, but looking at a LinkedIn button in the wild, I think the styles are all inlined anyway (and you could always duplicate them yourself under a new classname if you had to.)
Good luck!
* It's also possible that LinkedIn is storing a JavaScript reference instead of targeting via the classname. This will be harder to track down, but the same rule applies: find whatever part of the page LinkedIn uses to identify that button, and destroy it.
Related
First off, I want to say that I very little knowledge of coding so please bear with me. I'm trying to paste in a site that doesn't allow it. This is the link to the javascript that they used to block it, https://mychatdashboard.com/js/messages.js?v=1.3
A friend of mine is helping me with it and he suggested that I put this in the javascript console in the DevTools of Google Chrome,
handler = function(e){ e.stopImmediatePropagation(); return true; }
document.querySelector('#conversation-content .conversation-message-text').addEventListener('keyup', handler, true)
document.querySelector('#conversation-content .conversation-message-text').addEventListener('input', handler, true)
This does solve the problem but it creates another issue. It seems that it interferes with this section of the javascript that I have linked to,
* Function to update the messagebox. (Enable/disable send button,
* change the color class, update the counter)
* #return void
So what would happen is that when a message is typed in the textbook, there's a character counter at the top which shows how many characters are written. When 80 characters(I think it's 80) are typed, the send button will be enabled so that I can send the message. However, with the javascript code that my friend suggested that I used, it stops the counter from working altogether so the send button never gets highlighted.
Is there any way around this? Please let me know if further clarifications are needed since it's the first time I'm asking a question of this nature.
The JavaScript you're entering into the DevTools console is defining a function named handler and then adding it as an event handler for keyup and input events for a field on the page you're viewing (presumable the chat window textbox).
The way that the handler is defined and attached prevents other events from firing (such as those that enable the send button when you've typed enough characters).
For this sites (and I haven't been able to test it) instead of the code you've used you could try running this in the DevTools console (once the page is loaded):
restrictCopyPasteByKeyboard = function () { return true; };
This should redefine the function that's preventing you from using paste (I can't test it out because I can't access that site).
There are numerous way through one can copy contents from Right Click protected sites
By disabling browser JavaScript in browser
Using Proxy Sites
By Using the source code of the site
Disabling JavaScript in Browsers [Google Chrome]
In Chrome browser, you can quickly disable JavaScript by going to settings. See the screenshot for better explanation:
screenshot
Through Viewing Source Code
f you have to copy the specific text content and you can take care of HTML tags, you can use browser view source options. All the major browser give an option to source of the page, which you can access directly using the format below or by right click. Since, right click is out of question here, we will simply open chrome browser and type: view-source: before the post URl Like
view-source:Enable copy and paste for a site that doesn't allow it
Press ctrl+u
And find the paragraph or text you want to copy and then paste it into any text editor.
I'm sure there are many ways of restricting user's ability to copy/paste. In my experience, it's always been a JS function that you can overwrite.
Slight variations of the below have always worked for me:
document.getElementById("#ElementWithDisabledPaste").onpaste = null
Is it possible to have a radio button in an alert box?
The requirement is, not to use any modal box, that why we just think if it's possible with alert box or confirm box. then we can good to go.
Any help will appreciate.
Sample Screenshot is below.
i don't guess. i know that this is in fact impossible.
the reason is simple:
alert(), prompt() aswell as confirm() were part of html + js since js exists.
they never got deprecated though they break the asyncronous flow of javascript.
this is essentially why they only allow you to play around with strings.
they were never intended to be feature rich.
they were actually invented out of the blue because the inventor (Brendan Eich) thought they'd come in handy. (wich at that time was more than enough for everyone)
they are by design blocking operations and should be avoided as much as possible.
to get around them simply create a so called modal dialog (thats basically a <div> with position: fixed above the pages content.
benefit:
you can easily make it appear as you want and you would not break any network connections or behavior of your application.
PS:
don't use w3schools as reference for learning or anything else.
they are a low quality database. you should look stuff up on mdn or other sites but should seriously avoid w3schools since it's not feature complete on any topic.
keep in mind this is an opinion.
It is impossible to use radio inside of alert window.
Message parameter in window.alert(message); has a string type and you cannot put Object or HTML there (will be transfomed to string).
Do not overuse window.prompt() Method , as it prevents the user from accessing the other parts of the page until the box is closed.
Window prompt Usage Note
Imagine you have a simple, single-page application - regardless of whether it was written using Backbone, Angular, Ember or anything else.
How can you tell a screen reader that we've changed 'page' when a route is followed?
In a classic application, when I navigate from /index.html to /about.html the screen reader obviously detects the page change, and re-reads as you'd expect.
In my Backbone application though, when I follow a route I cannot work out how to trigger a 're-read'. I've tried triggering a focus event which I'd seen somewhere, but that doesn't seem to work.
Note: I'm currently testing with NVDA/Chrome.
Overall, you should not need to trigger a 're-read', and depending on your UI that might not be a good thing anyway.
My experience has been with angular.js (as an accessibility person rather than the developer), and our overall approach was to manage the focus rather than trigger a re-read. (We do extensive accessibility testing.)
The key thing from a UI point of view (primarily for screen reader users) is that selecting a link (e.g. about.html) should take you somewhere.
In this case the appropriate place to put the focus would be the top of the content area of the about 'page', hopefully an <h1>.
In order for that to work the target element should be focusable via a script, so probably needs tabindex unless it is a link or form control:
<h1 id="test" tabindex="-1">
The -1 means it is not in the default tab order, but is focusable via a script. See more at WAI-ARIA authoring practices.
Then at the end of the function that loads the new content, including the tabindex attribute, add something like:
$('#test').attr('tabindex', '-1').css('outline', 'none');
$('#test').focus();
When adding tabindex dynamically it is best to do so in a line before the focus() function otherwise it may not work (I remember that from testing with JAWS).
To test this I would use either:
NVDA & Firefox, Windows
Jaws & IE, Windows
It is also good to test with VoiceOver on Safari/OSX, but that works differently and may not hit the same issues as a windows based screen reader.
You will hit a lot of issues with Chrome/NVDA as that is not supported very well, and end-users are very unlikely to use that. IE is ok with NVDA, but Firefox is best.
Overall, it is worth getting to know the WAI-ARIA authoring practices, particularly Using ARIA in HTML. Even though you are using a JS app, the browser (and therefore screen reader) is interpreting the resulting HTML so that advice is still relevant.
Lastly, if you are updating page content without the user pressing space/enter to activate something, you might find that JAWS/NVDA do not know about the new content as their 'virtual buffer' has not updated. In that case, you might need to add a JS shim to make them update, but only do that if you run into problems in testing, it should not be a global patch.
Taking the answer from #AlastairC, and the comments below it. I've taken this a bit further now and am going with this as my solution going forward:
My go-forward solution
I found that just reading out the first heading wasn't really that useful. Especially if the last page you were on was a loading sequence. You can hear that there something new has been focused, but it's certainly not clear that this forms the part of a whole now page.
Add some useful, descriptive text to the page
As such I now have a single paragraph at the top of my page layout template. This includes a screen-reader friendly message, along with a very rough overview of what the page.
<p class="screenreader-summary" tabindex="-1">
The <strong>Dashboard</strong> page is now on-screen.
It contains several widgets for summarizing your data.
</p>
Note that the tabindex value allows us to focus this element with JavaScript. You might not want to use a p element for this, you can use anything you like really.
Hide it off-screen (optional, only required if it would break your design/readability)
This is then coupled with CSS to move this element off-screen:
.screenreader-summary {
position: absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
outline: none; /* Important, don't show an outline on-focus */
}
Focus this element, when a new page is shown on-screen
Finally, in the JavaScript code that shows your page on screen (e.g. in MarionetteJS using onShow or the show event):
$yourViewEl.find('.screenreader-summary').focus();
The result
I'm a sighted person, so take what I say with a pinch of salt - however I found that reading out a short description is so much more useful.
For angular the url changes, If someone REALLY needs to reread everything, (like me because of requirements), what did the trick for us was this:
$(window).on('hashchange', function () {
location.reload();
});
and we just added extra code to handle pages like "success" were no reloads are supposed to happen.
this simulates the actual page loading, and screen readers will read it normally like a page change.
kind of defeats the purpose of angular in a way, but this will help people like me who already have the application, and want a quick fix.
I'd like to add an onbeforeunload javascript, asking the user to bookmark the page (there's a small button in the header for that purpose).
The problem is, no matter if they'd like to bookmark it, it's pointless and annoying after running once.
So, what's a generic solution to stop a javascript from running more than once?
Thanks,
Emilia.
EDIT:
Yes, I guess an onload event would be more appropriate?
I don't really want to add "big red buttons"...
Any basic example how a IP validation + script would look like?
I would say it's already a bad idea to use a pop up when the user wants to exit the page even if it is only once, it's annoying and obtrusive. I suggest you place a big button on site itself if you want to call the visitor to an action, bookmarking in this case.
If you still want to though, you should use IP validation and not cookies, cookies are temporal, they can be removed by the user, and visitors will not like to be presented the same suggestion over and over.
I have made few changes on this huge JSF page, which is full of Javascript as well. I dont know which change make the problem happen.
The problem is: after some Javascript is executed, all the text fields in the page become readonly. The problem is not occurring in IE7 nor in Firefox. I have debugged all the javascript, there is no errors thrown! And there is nothing telling the fields to become readonly, since its working correctly in IE7.
Not sure what the problem is, could be CSS related? or Javascript? And why is it happening on IE6 only?
Note: "Don't support IE6 is not an option"
While IE may be buggy make trouble in some situations, I'm quite sure this is not an IE bug.
How do you tell the fields are read only? Do you get any optical confirmation or is it just that you can't click them any more? In that case, I'll bet you a beer that is's some invisible DIV or other layout element that, due to some CSS setting, squeezes itself above the input fields.
Try the IE developer toolbar to find out whether it's a layout problem.
If they are really disabled as in <input disabled> you need to show some JavaScript or (better) a link.
Still not sure what happened with that build, but what i was sure about is all the Ajax modifications i did was responsible for the problem.
The scenario was like:
Fill textfield1 (hit getValues1 , then hit a validate Ajax)
Fill textfield2 (hit getValues2 , then hit validate on both values together)
Fill textfield3 (hit getValues3 , then hit validate on all three values)
And a forth time again the same scenario. The page was built by a new to JSF guy, and it was very huge. I took long time refactoring it. But now its much better, each text field still have a getValues Ajax, but instead of validating them after getting all the values, i filter the allowed values on the server by sending the chosen criteria
The scenario now:
Fill textfield1 (hit getValues1 Ajax)
Fill textfield2 (hit getValues2 Ajax with value of 1, and get only allowed values)
... etc
The problem seems to be an Ajax racing conditions and at some moment IE6 was hanging or stuck in a deadlock, im not sure.
Lesson learned, "Refactoring once may take a week, but without every single issue will take longer"
um... don't support IE6??? ;)
Suggest disabling your CSS and seeing if the problem goes away. I'm not aware of any CSS tags that can disable a field, though.
Other than that, debugging is your only option. Remove all your .js and add it back in line-by-line until something breaks.
It will probably be hard for us to help you without seeing some code.
See if the HTML for the page has the 'disabled' attribute set on those INPUT elements. If so, then javascript is being used to enable the elements after the page has loaded. This is a not-uncommon technique to keep users from prematurely trying to interact with a page before all scripts have loaded.
If that's what is happening, then what you've probably done is break the way the script recognizes which elements need to be enabled. Since this is only happening on IE6, it sounds like the script might be doing some esoteric DOM navigation, which broke as a result of changes to the markup or CSS.
Unfortunately this is something you'll have to debug by reverting back to previous versions until you identify the change you made that broke the page.
Based on the other answers here, and some of your comments to them, it seems there is a JavaScript function in your page that sets elements to be enabled or disabled.
In order to help, we would have to see your code. Here is something you can do yourself, though, that would solve your problem:
Find that function (or ANY function) that sets elements in your page to disabled or enabled.
Depending on your development environment, there are different ways to do this, but somehow add a breakpoint there at the function.
Load the page.
Whenever that function is called, code execution will stop at that function. Whenever it stops, make sure that it was supposed to be called (and watch the call stack).
Eventually, you'll hit that breakpoint at a point where you weren't supposed to. Look at the call stack to see what caused it (which function resulted in a call to this function).