Working on implementing/fixing the accessibility features of my client's website, we stumbled on the particular case that Firefox decides to set focus to an <iframe> when tabbing through a page, which no other browser does. The client then suggested that the <iframe> content be given a title attribute (in the <head> of the loaded HTML) so that the VoiceOver feature (and its equivalents) reads the <iframe> title out loud.
This works when tested in a void, as you can test here:
http://dev.jansensan.net/tests/iframe-title-accessibility/
http://dev.jansensan.net/tests/iframe-title-accessibility/one-time-payment.html
So in the context of the project, this should also work. However the browser keeps saying "Firefox busy" no matter what we tab onto.
What would cause this situation? I have tried asking on the Mozilla Support forums in the hopes of being pointed to some documentation that would provide some guidance, to no avail.
We would appreciate some guidance, in order to see if we need to change something in our content, or if this is an issue with Firefox itself.
Related
TL;DR
How/why are some browsers able to search and highlight text in the HTML body which is followed by #:~:text= in the URL?
Explanation
One day I was searching for something on Google, which lead me to Quora's result. I observed that 2 sentences were highlighted in yellow, which were part of URL after the aforementioned parameter. I thought this would be Quora's feature for SEO or something, however, also found this on Linkedin, and Medium, and so on.
I'd like to know:
What is this highlighting called? Why/how does it work?
This seems to be browser-specific. What kind of browsers support this?
It seems to work on Chrome and Edge; but not on Firefox, Safari, and IE.
Does a frontend programmer need to incorporate something in the code to have search engines highlight content on their web-pages? (Based on the assumption that search engines actually appends the relevant string predicted by user's query)
The highlighting is called Text Fragments. Its a new feature that was recently added to Chrome 80. It works by specifying a text snippet in the URL hash.
Yes it is browser specific.
No, the experience that you get when clicking on a link from Google's search results is part of Featured Snippets which are algorithmically determined. There is nothing you can incorporate into your code to prompt search engines to highlight text on your page.
There is no markup needed by webmasters. This happens automatically,
using Scroll To Text for HTML pages
https://chromestatus.com/feature/4733392803332096. See also more
background here: https://support.google.com/webmasters/answer/6229325
Sources:
https://web.dev/text-fragments/
https://www.theverge.com/2020/6/4/21280115/google-search-engine-yellow-highlight-featured-snippet-anchor-text
https://www.theverge.com/2020/6/18/21295300/google-link-to-text-fragment-chrome-extension-chromium-highlight-scroll-down
https://searchengineland.com/google-launches-featured-snippet-to-web-page-content-highlight-feature-335511
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html
While text fragments is natively implemented only in latest Google Chrome (and the latest versions of Chromium-based browsers, such as the new Microsoft Edge), there is a browser extension/add-on that seems to enable it on Firefox and Safari: https://github.com/GoogleChromeLabs/link-to-text-fragment
It appears to use #ref-for-fragment-directive:~:text= and additional arguments (instead of just simple #:~:text=).
Firefox: https://addons.mozilla.org/firefox/addon/link-to-text-fragment/
Safari: https://apps.apple.com/app/link-to-text-fragment/id1532224396
Curiously enough, the extension has also been made available for Chrome and Edge too (!).
.
UPDATE: I'm testing it on Firefox Developer Edition, and it doesn't work for me.
I use Chrome as my default navigator and it's been a while that I have to appeal to other browsers (or external tools like Dash) whenever I need to read some apple documentation because Apple docs menu style is just broken for me on Chrome.
The unusual thing is that it does not seem to be a CSS incompatibility issue, but seems that the DOM is not being created accordingly to the page's HTML.
This doc page, for example, has this HTML for the menu:
<menu id="bashful" type="toolbar">
<div class="shield"></div>
<menuitem id="jump_to" class="menu-bar-item closed">
<span>On This Page</span>
<div class="chevron"> ... </div>
<menu type="list" class="details">
<ul class="list-bullet">
<li class="item">
Mutability of Collections
</li>
...
</ul>
</menu>
</menuitem>
</menu>
Ignoring their poor indentation, it is pretty clear that all menu items are inside the <menuitem> tag, but when inspecting my chrome elements tab, it does not show that, it shows the <span> and <menu> tags all outside it, making a lot of CSS selectors rules to stop applying.
Here is how it is being shown on Chrome (buggy)
and Chrome Canary (works properly),
This tests were done with the following browser versions
Chrome Version 45.0.2454.101 (64-bit) - breaks
Chrome Canary Version 48.0.2528.0 canary (64-bit) - works
Firefox 40.0.3 - works
Safari Version 8.0.8 (10600.8.9) - works
First I suspected it to be a simple browser incompatibility issue, so I tried to replicate the problem asking for other people with the same browser to test Apple docs link, but so far I was the only one with this "problem"
I already also tried:
Disabled all browser extensions
Disabled/Clear all browser cache
Compared both browser downloaded HTML and CSS resources but they are identical
I created a codepen with just this piece of HTML and the same issue occurs without all other Apple docs garbage if you want a simple HTML for better analysis
I checked <menuitem> on mdn and it seems that the label attribute is "Required when a command attribute is not present", but it this enough to break everything on Chrome? Is Apple using <menuitem> for purposes other than the intended in the specification?
Well, does anybody know what might be the cause and what are possible solutions to this annoying issue?
This is part of Chromium issue #87553 "Implement HTMJ5 menu tag".
menuitem parsing is implemented a year ago on Aug 2014.
Overall, it seems to be mostly done, but the feature is still "in development" and is not yet "shipped", so it is disabled by default in stable channel.
When it is not enabled, current stable Chrome (v.45) does not know menuitem and parse it as a normal element requiring end tag, instead of as a content-less element without end tag according to spec.
But if you enable the "Experimental Web Platform Features" Chrome flags, your code will be parsed correctly.
For now, you can make sure the tags are properly closed.
(Self-closing, as the spec suggested, does not work for Chrome.)
As long as the menuitem is empty, standard compliance browsers will ignore it and there is no harm done.
P.S. Technically, throwing error and stop is also standard compliance, but no browser really do that.
These are (usually and currently) the only compliance options - die or ignore.
P.S.2 In case it is not clear, as of Oct 2015, menuitem element cannot and should not have content, and this part is the same as the Jan 2015 spec.
According to the MDN Documentation, the <menuitem> element is an experimental technology and it must be nested as a child element of a <menu> element. The element is supposed to provide HTML access to context menus i.e. for right click menus. It has only been officially supported by Firefox. Officially, none of the other browsers support it, which means that it's rendering would be undefined. It may be handled as XML data, or it could be mishandled as some other HTML element that the browser has a definition for, but that's purely speculative.
I find it curious that Apple is using an experimental HTML element that Safari, Apple's own browser, does not officially support. Perhaps they intend to support the element in a future version of Safari, and one of their web devs jumped the gun by using it in a production environment. Even if the element was supported, it still may not function correctly. The current documentation states that there are required attributes (either one of label or command) which are not used in Apple's code. So the code would still be bad even if it was officially supported.
The short answer is: Apple screwed up, and they need to fix their HTML.
Meanwhile the only "possible solution" for users is to use a different browser. On the developer side, though, there is a nicer solution. If you want to learn about the way that context menus are supposed to be implemented in Chrome, Google has provided an API for that purpose.
I found this completely wonderful document that shows the information I want, but for IE9. This helped clear up a lot of confusion I had about how IE document modes work:
http://ie.microsoft.com/testdrive/ieblog/2010/Jun/16_IEsCompatibilityFeaturesforSiteDevelopers_1.svg
I've searched for an updated version for IE10 but haven't found anything. Anyone seen the equivalent but updated?
My experience so far with msdn's documentation such as their Defining document compatibility has been very frustrating, with a lot of going in circles and undefined terms.
Particularly, the question I've been unable to answer (though really I'm only looking for the answer still because I'm frustrated that it's not provided anywhere) is this: Does IE10 Compatibility Mode still mean it's emulating IE7? I guess I assume that it does, but it annoys me immensely that nothing seems to say so explicitly. Mad props to anyone who can find someplace that the MSDN documents say whether it does or not.
I was also looking for an updated diagram, and found the following after doing a Google image search (scroll to bottom):
http://msdn.microsoft.com/en-us/library/ff955275(v=vs.85).aspx
There are links on the left to take you to the compatibility view settings and doctype table, as they're not included in the flow chart on the page.
For your second question, about whether Compatibility Mode is still emulating IE7, I assume you mean that you get to IE10 Compatibility Mode by clicking the icon in the browser and not by setting a meta tag or header. I believe the answer is yes, but not because I have seen it in Microsoft's documentation. When I click that icon and look in Developer Tools, I see that the Browser Mode is "IE10 Compatibility" and the Document Mode is "IE7 Standards" so it seems like that's the default. You can see this happen on nytimes.com.
The "postMessage" is an HTML5 API, it is available in all major browsers including IE8/9. What I am trying to do is to create a popup window from a page, and be able to talk to the popup window using "postMessage". This works in every browser except IE8/9. Disappointed!
It looks like IE8/9 only allows the communication between iframes, but not between two windows, even the windows are within the same hierarchy.
I found that .postMessage() in IE9 was unreliable unless I used Strings.
My workaround was to simply call .postMessage(JSON.stringify({object: 'data'})) and use JSON.parse() in the onMessage() function on the other end.
The .postMessage method works, you just need to understand how it works from IE8 and up. Unfortunately, for IE8 and IE9 it will not do what you're seeking (though it does in IE10). While you can send messages between frames in IE8/9, you cannot send messages to a separate window.
There is a work-around that works in some instances. Martin Beeby discusses it in the last paragraph of his blog post on the issue: PostMessage Popups and IE.
For more on this, and a few other caveats, see Eric Lawrence's post on MSDN.
I've been working on a revamp of the charity site I'm the webmaster for, heroinitiative.org. It is located here:
http://www.heroinitiative.org/revamp/default.html
(and no it's not live code, it sits alongside the live site just so I can show progress to my boss, it's not really important to keep it under wraps, which is why I can post it here)
My problem: For some reason all links in the footer (from id "bodyfooter" on down, including anything I put below the "Partners/Thanks" footer) have been disabled. I don't know why this is happening as I've thoroughly reviewed the code.
It happens in:
Firefox 3.6.8
Chrome 5.0.375.127 & 6.0.472.53 (just upgraded as I typed this)
but not in:
IE 8.0.7600.16385 (or in it's compatibility mode)
you have a z-index:-1 on #bodyfooter. main.css line 182
remove this or change it to 0.
Your page takes a long time to display in Safari on my Mac.
Whenever I have a page that does not render as I expect, I run it through the W3C Markup Validation Service.
Try fixing the errors displayed here:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.heroinitiative.org%2Frevamp%2Fdefault.html&charset=%28detect+automatically%29&doctype=Inline&group=0