I'm having a strange issue with IE9 where if I have multiple <div> elements on the page, where only 1 is visible at a time and then others are shown as a result of JavaScript actions on the page.
The issue I am having is that if an element is hidden (seems to only happen after being hidden for a certain amount of time), when I go to show the elements w/ jQuery $('.className').fadeIn(500); for example, the background image properties of the elements inside that DIV that is being shown are lost.
They are still there when inspecting the HTML w/ IE Developer Tools, but the background image seems to not be recognized for whatever reason. In the developer tools, I can click to edit the background image path, and simply hitting enter (not actually changing the path) makes the background appear.
Is there something with IE that makes it ignore elements if not displayed on the page for a certain amount of time? Any help would be greatly appreciated. This is very strange as this was never an issue for me in any other browser or any other version of IE.
Related
$('#firstButton').focus();
<div id="liveRegion" aria-live="assertive">
This is a very long text
</div>
<button id="firstButton">First Button</button>
I am quite a newbie in accessibility issues. I basically have a button on which I want the focus to be on page load, but I also want a text to be picked up by the screenreaders in the liveRegion.
Right now, the text will be inteerrupted at some point during page load, and focus goes to the button.
Is there a way to have the screenreader not be interrupted?
Live regions can be confusing at first. The purpose of a live region is to announce changes to the page, not to announce page load information. After your page is loaded, if something changes on the page, such as the text within an element, or a new element is added, those changes can be announced if the aria-live attribute is used.
Most pages do not announce anything as they're loaded. A screen reader user will hear that the page is loading, and when it's done (usually there's an audible clue in the screen reader to let you know if the page is still loading or if it's done), the page title is typically announced and then whatever object has initial focus is read.
If you really need something read after the page loads, then it should probably have the initial focus. But be careful because putting focus on a non-interactive element such as a paragraph (<p>) or non-semantic elment (<div>) can be confusing. If you have to resort to that, make sure that element has tabindex="-1" so that the element will not be in normal keyboard focus order.
as such, there is no way to prevent the reading of your text by the button gaining focus.
The order of priority of what to say when heavily depends on screen reader / browser / OS combination, but usually, an element taking the focus has priority against any live region, including assertive.
What you can do is making the live region assertive text appear after the focus is moved to the button.
It has greater chances to be announced without interruption then.
IN any case, a live region present at page load isn't reliably read on all platforms.
To make sure that it will be effectively spoken, make it appear in the DOM after the page has completely finished to load.
I have a page with multiple tinymce textareas, using the browser's default context menu. The issue I'm having is that sometimes Chrome will show the correct textarea context menu (cut, copy, paste, etc.), but every second time I open the context menu (roughly), it shows the non-textarea content menu (back, forward, reload, etc.)
I've a sample Fiddle here demonstrating the issue: http://fiddle.tinymce.com/Bugaab
If you right click in either text area (in Chrome) a few times, in different locations, the different menus will appear.
I'm fairly sure I'm initializing the controls correctly. The problem doesn't occur with only a single textarea.
Any help appreciated.
Not quite. It's not a tinymce context menu at all. That's Chrome's context menu when it opens inside an input or textarea. It has different menu items depending on the context.
I said earlier that the issue didn't occur when only a single tinymce textarea was on page, but I see now this was incorrect. The issue happens for every tinymce textarea.
I think the problem is to do with the area of the textarea. Tinymce hides the actual native textarea control and draws its own, and it’s probably incorrectly mapping the dimensions somehow, confusing Chrome into thinking the mouse click is outside the control.
From what I’ve seen, the norm with this control is to use its own context menu rather than rely on the browsers, which is probably why I’ve had such difficulty finding mentions of the Chrome problem anywhere.
I'm looking for a chrome feature similar to debugger/breakpoint that lets me pause a script.
Why. I like to test some css in chrome-inspector. Since it's a loading spinner it will only be visible for some milliseconds. That time is to short to play with css ;)
Why not breakpoint...
Because chrome covers the entire page with a black layer so I cannot right-click and inspect a DOM-element as I like.
So is it possible to get rid of the black layer chrome has in debegger mode? or can I simply pause a script, play around with the css and the play it again.
Thanx in advance.
In your Javascript, you can simply write:
console.log(element);
debugger;
When the Chrome developer tools console is open, this line will pause your script without placing a breakpoint manually. console.log(element); will let you access the element you wish to debug or modify via the console.
After the script stops, you can use the DOM explorer, select your element, and in the DOM properties window, under "Styles", change its display property to none to make it disappear.
I found an ok answer to my own question. Simply use the select-element tool in chrome rather than right click.
Icon to the left
It temporary removes the black-layer until the element is selected. But if you want to see the correct colors without the black layer covering it you need to display:none it in the inspector. Also if you want to work on hovers or other similar stats the black layer will prevent hovers and such.
I have the following element:
And then I use jquery fadeOut(), then remove() method to remove the yellow element.
This works perfectly in every browser except in android Chrome, which looks like the picture above.
The element is supposed to be removed, yet still, it exists on the screen unless I change the phone orientation.
I used chrome inspector, through Remote debugging, to check the element, and indeed the element is removed as revealed in the element panel. I just wonder why the element still shows on the screen.
The element with class LMnwtItem clearly is left with one, with display being none, yet on the screen, still showing the element.
Any help is much appreciated.
btw, sorry for being unable to show the codes.
ONE MORE INFORMATION WHICH MAY HELP
The element, however, will disappear after hiding the parent element and then showing the parent element again, but only manually.
I'm having some strange issues in Safari on Mac desktop and on iOS on a site currently being built. It seems that when there are jQuery interactions with elements, the elements disappear. When I inspect the element, I can't see any properties that indicate why the element would be hidden. If I toggle one of the checkboxes on any of the CSS properties for the element, it reappears.
Steps to Recreate
In Safari, go to: http://bisqitstage.promotw.com/
Refresh the page using the refresh button (not by hitting return on the URL).
Click the darker area (intended checkbox) to the right of "I agree to the terms and conditions of the site.".
Here is where you should see a checkmark appear based on the jQuery event.
Right click the box area and choose "Inspect Element".
In the HTML inspector, within div.bisqit-checkbox click on div.glyphicon.glyphicon-ok.check.
Scroll down within the CSS inspector and toggle the checkbox next to any of the property options (for example, uncheck and then re-check width: 35px;).
The checkmark will now be displayed
Expected
After step 3, the checkmark should be displayed after step 3. When inspecting in step 6, if you chose "width" for instance, the property was already checked. Unchecking it and checking it again shouldn't change it's state - so why does it not display after step 3?
I'm having several issues similar to this within this site build. I've tried different jQuery versions as well as removing other components that might be interfering, but cannot seem to resolve the issue.
Browser Version: Safari 7.1 (although we've noticed it back to v6).