Develop Reference

How to add Keyboard navigation( Accessibility Access) to existing website using JavaScript, CSS or HTML?

How to add Keyboard navigation to an existing website using JavaScript, CSS, or HTML?
I don't want to add any paid apps. if you know free javascript library or something let me know.
similar techs I used:
tabindex="0",
a:focus{border : solid 2px blue}

Some concrete advice:
Use standard HTML5 elements where possible. Read up on HTML5 semantics, in particular headings and navigation. Before reaching for custom classes and CSS display/visibility features, make use of HTML attributes like hidden and disabled to control the visibility and availability of content and UI.
By all means use <div> and <span> elements for presentation and layout, but pay attention to document structure. Let semantic markup reflect/express the meaning you intend. ARIA landmark roles can help, although most of them are implicit in HTML already.
Note that the "Outline algorithm" mentioned in the HTML5 spec is not implemented on any browser, so don't get too hung up on perfectly sequential heading levels, just be consistent and logical. I find that starting each landmark with a new <h1> tends to be easiest to manage, but others prefer to have only one <h1> per page (thereafter starting distinctly meaningful areas or landmarks with <h2>). Both approaches are acceptable, and the exact choice should depend on complexity and did I mention consistency?
Add ARIA attributes sparingly, and only when HTML does not already express the intended semantic. (e.g. adding aria-pressed to a <button> turns it into a toggle button). No need to add aria-disabled="true" if the element already has a HTML5 disabled attribute.
It's worth knowing that ARIA attributes work well in CSS attribute selectors. If you use them, you can style your content based on their values, which keeps things synchronised.
Ensure that all operable/interactive elements are clearly labeled using standard HTML mechanisms like <label> if possible. If a visible label is not desired, or is ambiguous without visual cues, you may use aria-label to provide an 'offscreen' one.
More complex interactions may need some special keyboard handling in javascript.
Pay attention to the many articles offering guidance about color and contrast (for users with low-vision or color blindness). In particular, make sure the keyboard focus indicator is always clear and obvious. (You mentioned the CSS outline property in your question, so you are on the right track).
Provide text alternatives for all non-decorative images. If you're using an <img> tag, the alt attribute works very well. Decorative images need this too, but with a null value. (e.g. alt="")
Bear in mind different screen sizes and orientations. Consider using responsive CSS features such as media queries, grid and flex layouts. Avoid re-ordering content visually when it contradicts the meaning of the sequence in the underlying HTML code.
Consider that users may want to increase text size or line spacing using custom settings. This means leaning on relative units such as %, em and rem, rather than px, which should be reserved for hairline borders, or media query breakpoints.
VALIDATE YOUR CODE using an HTML validator. Free dev tools such as axe-core will also give very useful feedback and helpful guidance.
Use stack overflow for concrete questions. It's pretty reliable. Many good accessibility questions have already been asked and answered. Search first!
If you follow this advice, and if your product is not too outlandish in design, you will most likely be able to approach a high level of conformance with WCAG A/AA without too much pain.
Finally: Transparency is more important than full conformance. If you have WCAG violations you can't fix in the current iteration, be open and honest about it, and you will be in the clear, legally speaking. Perfect conformance is rare, and especially so for a first time accessibility implementation. Welcome to this challenging and rewarding field, and good luck!

Javascript retrieve linebreaks from dom [duplicate]

I need to add line breaks in the positions that the browser naturally adds a newline in a paragraph of text.
For example:
<p>This is some very long text \n that spans a number of lines in the paragraph.</p>
This is a paragraph that the browser chose to break at the position of the \n
I need to find this position and insert a <br />
Does anyone know of any JS libraries or functions that are able to do this?
The only solutuion that I have found so far is to remove tokens from the paragraph and observe the clientHeight property to detect a change in element height. I don't have time to finish this and would like to find something that's already tested.
Edit:
The reason I need to do this is that I need to accurately convert HTML to PDF. Acrobat renders text narrower than the browser does. This results in text that breaks in different positions. I need an identical ragged edge and the same number of lines in the converted PDF.
Edit:
#dtsazza: Thanks for your considered answer. It's not impossible to produce a layout editor that almost exactly replciates HTML I've written 99% of one ;)
The app I'm working on allows a user to create a product catalogue by dragging on 'tiles' The tiles are fixed width, absolutely positioned divs that contain images and text. All elemets are styled so font size is fixed. My solution for finding \n in paragraph is ok 80% of the time and when it works with a given paragrah the resulting PDF is so close to the on-screen version that the differences do not matter. Paragraphs are the same height (to the pixel), images are replaced with high res versions and all bitmap artwork is replaced with SVGs generated server side.
The only slight difference between my HTML and PDF is that Acrobat renderes text slightly more narrowly which results in line slightly shorter line length.
Diodeus's solution of adding span's and finding their coords is a very good one and should give me the location of the BRs. Please remember that the user will never see the HTML with the inserted BRs - these are added so that the PDF conversion produces a paragraph that is exactly the same size.
There are lots of people that seem to think this is impossible. I already have a working app that created extremely accurate HTML->PDF conversion of our docs - I just need a better solution of adding BRs because my solution sometimes misses a BR. BTW when it does work my paragraphs are the same height as the HTML equivalents which is the result we are after.
If anyone is interested in the type of doc i'm converting then you can check ou this screen cast:
http://www.localsa.com.au/brochure/brochure.html
Edit: Many thanks to Diodeus - your suggestion was spot on.
Solution:
for my situation it made more sense to wrap the words in spans instead of the spaces.
var text = paragraphElement.innerHTML.replace(/ /g, '</span> <span>');
text = "<span>"+text+"</span>"; //wrap first and last words.
This wraps each word in a span. I can now query the document to get all the words, iterate and compare y position. When y pos changes add a br.
This works flawlessly and gives me the results I need - Thank you!

I would suggest wrapping all spaces in a span tag and finding the coordinates of each tag. When the Y-value changes, you're on a new line.

I don't think there's going to be a very clean solution to this one, if any at all. The browser will flow a paragraph to fit the available space, linebreaking where needed. Consider that if a user resizes the browser window, all the paragraphs will be rerendered and almost certainly will change their break positions. If the user changes the size of the text on the page, the paragraphs will be rerendered with different line break points. If you (or some script on your page) changes the size of another element on the page, this will change the amount of space available to a floating paragraph and again - different line break points.
Besides, changing the actual markup of your page to mimic something that the browser does for you (and does very well) seems like the wrong approach to whatever you're doing. What's the actual problem you're trying to solve here? There's probably a better way to achieve it.
Edit: OK, so you want to render to PDF the same as "the screen version". Do you have a specific definitive screen version nominated - in terms of browser window dimensions, user stylesheets, font preferences and adjusted font size? The critical thing about HTML is that it deliberately does not specify a specific layout. It simply describes what is on the page, what they are and where they are in relation to one another.
I've seen several misguided attempts before to produce some HTML that will exactly replicate a printed creative, designed in something like a DTP application where a definitive absolute layout is essential. Those efforts were doomed to failure because of the nature of HTML, and doing it the other way round (as you're trying to) will be even worse because you don't even have a definitive starting point to work from.
On the assumption that this is all out of your hands and you'll have to do it anyway, my suggestion would be to give up on the idea of mangling the HTML. Look at the PDF conversion software - if it's any good it should give you some options for font kerning and similar settings. Playing around with the details here should get you something that approximates the font rendering in the browser and thus breaks lines at the same places.
Failing that, all I can suggest is taking screenshots of the browser and parsing these with OCR to work out where the lines break (it shouldn't require a very accurate OCR since you know what the raw text is anyway, it essentially just has to count spaces). Or perhaps just embed the screenshot in the PDF if text search/selection isn't a big deal.
Finally doing it by hand is likely the only way to make this work definitively and reliably.
But really, this is still just wrong and any attempts to revise the requirements would be better. Keep going up one step in the chain - why does the PDF have to have the exact same ragged edge as some arbitrary browser rendering? Can you achieve that purpose in another (better) way?

Sounds like a bad idea when you account for user set font sizes, MS Windows accessibility mode, and the hundreds of different mobile devices. Let the browser do it's thing - trying to have exact control over the rendering will only cause you hours of frustration.

I don't think you'll be able to do this with any kind of accuracy without embedding Gecko/WebKit/Trident or essentially recreating them.

Maybe an alternative: do all line-breaks yourself, instead of relying on the browser. Place all text in pre tags, and add your own linebreaks. Now at least you don't have to figure out where the browser put them.

contentEditable insert br when new line occurs

A contentEditable has automatic word wrapping, creating a new line when you reach the width of the editable area. This is great but I am parsing the contents of this afterwards and I need it to add a <br> when it does this. I have tried everything I can think of and I can't achieve this. Any help greatly received.

This is not possible, the word wrapping point is 'browser discretion' and as such susceptible to font size differences, fonts not being installed, font render engines, anti-aliasing settings etc. etc. The line-wrap point is, so to speak, 'not your problem' from the browser's perspective, and as such it doesn't give this info away.
Theoretically you could rebuild the content word-for-word in JS in a dynamically sized and similarly styled div, and monitor for when the height changes - that's where the newlines occur. It'd be a crap load of crappy code to achieve a dodgy result though.
I can't help but feel like you're asking for an XY-solution here - if you need newlines at the given point, let the end user give them when he wants to. Simply adding overflow:auto;white-space:nowrap to the editable element forces them to. Example here.

Instead of finding elements from selectors in jquery can I do the other way around?

Usually we search elements by selectors in libraries like jquery but what happens if we want to make the other way around: given an element we want to find all rules applied to it like firebug does it!
This kind of job is necessary if we want to bring a css file and update it so we can see live results in our webpage.
In firebug by selecting an element we can see in reverse order all the rules that were applied to it.
First, we have to find the document's style rules and retrieve their contents as a text so user can update them but the real problem is to find the relation between an element and all the rules....
Is this possible even with the help of a library like jquery?

I was looking for opinions about what tools can one use to tackle such a problem in the restrictions applied by a browser environment...
My opinion is that we have to make a brute search attack at the css files/selectors and construct the dependencies: suppose we have 100 rules for a page with 100 elements the possible combinations are 10^4 as the relations are many-to-many.
Then, we can build 'tables' in memory (hash arrays) that might excced 10^4 records if we want to keep the cascading order of rules for an element.
Anyway, my point is that I wouldn't dare to put jquery in such a pain! If we can 'transplant' the heart of jquery, it's search engine I mean.
It seems that it's heart listens to the name of 'sizzle' but it's a waste of time here (regular expressions? no thanks). I think the real 'heart' is a simple word: 'querySelectorAll' and now we are running with native speeds here...
just an opinion since I don't care about wide/old browser support.

Searching for the Ultimate Resizing Textarea

I'm wanting to provide a resizing textarea control for users. I've given this a go and looked at a number of other implementations, but I can't seem to find one that meets all my requirements. Specifically I want a control that:
Works in IE6, IE7, IE8 on Windows and Firefox 3 and 3.5 on Windows and OS X when the page is rendered in standards compliant mode (i.e. not in quirks mode).
Does not mess up the undo buffer/undo stack. This is a particularly nasty issue with IE - adding nodes, removing nodes and some other DOM operations will reset the input buffer meaning that if an implementation relies on these techniques an undo will not behave like it does in a standard textarea control. I haven't been able to find much information about this bug except for this note. Implementations like the jQuery Auto Growing Plugin suffer from this problem - try undoing changes in IE and compare how this works to a standard textarea. I've added an example page demonstrating this problem to JSBin.
Has a maximum height beyond which the control cannot grow.
Shrinks appropriately when content is deleted.
Does not flicker or act strangely on keypress. e.g. jQuery Auto Growing Textarea control behaves strangely with, at least IE7, when the control has grown beyond it's initial size.
Does not require the control to use a fixed-width/monospace font.
The closest I've seen to something that works like this is Facebook's status update field, which is implemented as a content editable div element, but I have some reservations about using such an element because using a div means:
Need to explicitly style the border which means we could end up with a border that looks different to a native textarea.
Need to sync content with the real textarea (possibly in both directions?).
Adds complexity when placing hints and other elements relative to position of a textarea.
While this approach works for something like a Facebook status update, how well would it work in a form containing hundreds of standard input elements?
What I've set out above represents the "ultimate resizing textarea" - addressing what I perceive to be issues with existing approaches. Does such a control exist? Is it possible to write such a control?

Check out DOJO tools text area control
see more on this demo page (text area At the end of the form )
This closely come to your requirements.

You may need to roll your own to meet those requirements.
These could be a start.
http://tuckey.org/textareasizer/ (though try and avoid eval() in yours)
http://www.felgall.com/jstip45.htm
http://viralpatel.net/blogs/2009/06/textarea-resize-javascript-jquery-plugin-resize-textarea-html.html
This actually seems like a good jQuery plugin. I might have a tackle at developing something like this. If I get it done, I'll post it here.
I spent a few hours developing something, but then I found this one that seems to be really good.
http://www.aclevercookie.com/demos/autogrow_textarea.html

You want to auto-size the display? but leave the content the same?
That is all the scripts can do, adjust the display, and let you see more of your own text...

This A List Apart post contains an implementation that looks pretty close to meeting your criteria and contains a good explanation of what's going on.

Are any of these useful?
Textarea Resize JavaScript: Resize textarea using jQuery plugin
Smart Area: A Lightweight Resizing Text Area Plugin for jQuery
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 1
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 2
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 3
Resizable Body

I have been using nicEdit. It seems to have all that you need and the script is only 1700 lines with an MIT license so you could make any changes you need.