the following tag works, except it adds heading level 4 at the end of the entries on aria-tab
<h4 ng-if="voiceOver" class="keep-it-classy" ng-bind="getCurrentText()" aria-label="{{getCurrentText}}"></h4>
is there some way to stop it reading the header size outloud?
Headings allow for more structural, simpler navigation. Telling a user that something is a heading, is telling them that if they use heading navigation, they can easily return to this spot.
So the announcement:
heading level 4
Is very useful. It tells them that they are at a structurally important part of the page. It also tells them, that if they set the rotor to "headings" they can easily return to this spot by flicking up/down.
Now, this is all assuming that your tag is structurally important, and behaving as an actual heading, and not just pretty text. In this case you should use a different tag, and adjust with CSS to fit the styling you want. This is the most accessible solution.
You could also consider using the ARIA attribute role="presentation" on the element.
<h4 role="presentation" ng-if="voiceOver" class="keep-it-classy" ng-bind="getCurrentText()" aria-label="{{getCurrentText}}"></h4>
though I'm not sure if VoiceOver respects this for heading type elements or not!
Related
I'm fixing an old WordPress syntax highlighter plugin (the plugin owner abandoned it), and while fixing the PHP errors was easy, while I'm fixing it, I might as well improve accessibility as well.
My question is regarding the HTML structure for the code. I want to show the number on one side and the code next to it:
I figured the HTML would be something like this:
<section> <!-- Maybe article? -->
<header>
<h1>Sample HTML</h1> <!-- Maybe <h3> would fit my blog posts best -->
<div role="toolbar">toolabar buttons here</div>
</header>
<ol>
<li><span class="sh-r "><div </span><span class="sh-e ">class</span>=<span class="sh-s ">"grid"</span><span class="sh-r ">></span>
...
</ol>
</section>
But I'm not sure. Should the code be in an <ol> or a <table>? Are the spans for changing the color ok? Is the toolbar role appropriate? Am I missing something? If anyone has an example of an accessible code highlighter, I'd love to see it.
The way it is right now, it's a table with all numbers in one <td> and all the code in another!
Should the code be in an <ol> or a <table>?
I would say that <ol> is more appropriate than <table>.
Using a table here looks a bit like presentational purpose only. I wouldn't call a table with line numbers on the left and code lines on the right exactly a data table.
Are the spans for changing the color ok?
As as default and because you can't do better in HTML anyway, I would say yes, it's fine.
IF HTML has more specific elements to semantically indicate keywords, blocks, numbers, strings, variables, etc. then you would be strongly recommanded to use them instead of spans.
But there aren't really such specific elements, except maybe <var, <kbd> and/or <samp>; but their semantic signification has never been very clear.
However, as a higher level, you should be using <code> or <pre> to enclose the whole code, to mark it as such.
The problem is that, if you use those two elements, you can no longer use <ol> or <table>.
Perhaps the most acceptable compromise would be <ol><li><code>One line of code</code></li>...</ol>.
In any case, for specific things like marking keywords inside the line of code, you don't have another better choice than <span> in what HTML has to offer.
Is the toolbar role appropriate?
Given that you haven't given the code inside the div, it's a bit difficult to answer.
Normally, a toolbar should contain a set of buttons or occasionally other controls like dropdown menus, and in principle nothig else then that.
If the content of that div corresponds to this simple definition, yes, the toolbar is appropriate. Otherwise, no.
Not that it isn't very worth it to use the toolbar role for less than 3 buttons
As I can imagine here, this div contains only a single button to copy the code in clipboard. If it's indeed the case, then by the definition above, it isn't very appropriate.
I am trying to create a link that goes directly to a certain section of a different page. Here is what I'm doing.
I create an anchor point using the name attribute:
<a name="fish"></a>
<p>some content....</p>
I create a link with the # added to the end
"http://example.com#fish"
***note I have also tried the id method instead of name which still gives me the same issue.
example: <div id="fish"></div>
The functionality works fine and it takes me to the specific part on the page, the only issue is that it looks different on different browsers. What firefox displays is about 5 inches higher than what chrome displays.
It's probably because the a tag is taking up some space.
Easiest solution, use an id instead.
<p id="fish">some content....</p>
Make sure there's enough content below so it can scroll
Most browsers have the same css default value for common html elements, however it is possible that some elements have different attribute values for padding and margin.
One way to avoid these differences is explicitly applying the values in the css statements.
p {margin: 10px 0px}
If you do not want to do this, I recommend you put link exactly in the position where text is located.
<p><a name="fish"></a>some content....</p>
You can locate the link anywhere since the anchor element will not be visible in the viewport
This is fairly simple, so I'm sure I'm just missing something obvious.
Say I have this example code:
<main>
<header>Header</header>
<section>
Content
</section>
<section>
Content
</section>
<section>
Content
</section>
</main>
And initial CSS of:
main{text-align:center;}
section{display:inline-block;width:33%;}
So I have three columns taking up more or less a third of the page each. Now, because of the way the code is written, there will be white space on the page. My preferred method of dealing with this is to set *{font-size:small}, and then add body>main{font-size:0;}.
Of course, thats fine on a simple page, where the font is the same. However, with different sized fonts and header tags here and there, this doesn't work well.
I think I just misunderstood what it is that the > selector does, but what I'm trying to look for is a selector that styles an element, without applying said style to children elements. In this case, I want to style my main element, but I don't want the style affecting the header or section elements.
What is the right way to do this?
And before anyone suggests it, no, I do not wish to use the other methods for removing white space (HTML comments, moving the final part of the closing tag onto the next line, etc.), as they look ugly and I prefer my code to look as presentable as my page.
First off: I'm not exactly sure if this works and not able to thoroughly test right now. This should have been a comment but I'm lacking the reputation to do so. sorry.
The problem is that the font size is one of the properties that is inheritet from it's parent and values like "small" don't set absolute sizes, but relative to the inherited size. so I would try to reset the size right after your main layer, using an absolute value instead of a relative one
body>main>*{font-size:18px;}
The important part is obviously not using a relative size, however, I have no idea how this holds up to user-specified default font-sizes. also, you would have to ensure that any text that has a non-medium font-size (so in your case any and all text) is at the very least a grandchild of main since the font-size for all direct children will be overwritten.
hope this will help you; bw
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
I've read various posts on this subject and think I understand the usual points of failure. I find that my two product thumbnail images, under the "This Click'n'Pick Set Consists Of The Following 2 Products" heading, are clickable, but do not take me to the named <div> element further down the page. Instead, they cause navigation to http://www.premierrange.co.uk/#bundle_product_anchor_448, for example. I see this both in Chrome (18.0.1025.33 beta) and Firefox (10.0.1) on Linux.
http://www.premierrange.co.uk/index.php?main_page=clicknpick&groups_id=2&chosen_0=243&chosen_1=448
So for example there's an anchor targeting '#bundle_product_anchor_243':
<a href="#bundle_product_anchor_243" title="Click here to jump to the 70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
<img src="http://www.premierrange.co.uk/thumbnailer.php?filename=images/H77-700.jpg&height=100" alt="70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
</a>
This targets the <div> further down the page:
<div class="productSeparator" id="bundle_product_anchor_243">
<h1>Product number 1 in this bundle of 2 products</h1>
</div>
I've also tried making the <h1> inside the target <div> be the target instead, in case the target must be an inline element rather than a div, but nothing seems to work.
The <div> containing the badly behaving <a> is completely closed by the time the <div> containing the target element appears in the document. I don't think there's a problem with the target element not being defined at the point in time the <a> is parsed by the browser.
Manually adding "#bundle_product_anchor_448" to the URL does work.
I am aware that the page fails HTML validation on a large number of points, due to a large number of factors that I'm not going to be able to address easily. I'd have thought this basic 'jump to a named element' functionality should work regardless. The page is completely functional other than this little navigation quirk.
Anyone got any clues?
Try removing <base href="http://www.premierrange.co.uk/"></base> from the page header.
The <base> tag specifies the base URL or target for all relative URLs (the ones that don't say http://www.example.com/...) on your page. Without it, your link should function as intended though you may have to fix other links to accommodate this change.
While using the <base> tag in your application, the best approach would be to just use absolute URL's before the hash, with the absolute URL pointing to the same page you're in.
So, assuming that you are on the 'http://example.com/products/curved-glass' page, instead of
<a href="#bundle_product_anchor_243">...
you would need to include the absolute current URL before the hash:
<a href="http://example.com/products/curved-glass#bundle_product_anchor_243">...
Finding out the current URL is a trivial task in most of the environments, and this method also avoids the removal of your <base> tag, action which might have negative consequences in other areas of your application.