For good accessibility, should the text for screen readers be the same text as the web page?
Issue I am pondering: Context may be different for someone who cannot see the item "in context" visually.
For example:
My page has a table with a header row with text "Total : 200"
200 being the number of rows.
I can add aria-label for 'Number of orders is 200' for the screen reader on the actual 200 (it's within a span) so that the screen reader doesn't just say "200".
My question is should the aria label be something more descriptive like 'Total number of records is 200' given the lack of context for the visually impaired user. Or is it OK because they will have their own context from knowing how and why they navigated there, assuming a fairly simple page such as my example where essentially the page is a table of records.
Use caption to describe the table and then there'll be context.
If adding caption adds redundancy of context, like there are already headings to know the context, you may use sr-only CSS class to hide it from the UI but keep it for the screen readers. The below snippet is from the Bootstrap CSS.
// Only display content to screen readers
// See: http://a11yproject.com/posts/how-to-hide-content/
.sr-only {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
overflow: hidden;
clip: rect(0 0 0 0);
border: 0;
}
Avoid aria attributes if HTML semantic tags serve the purpose.
Related
What’s the default margin that HTML sets for its <body> tag? I noticed that there’s some automatic margin, but I’m wondering if anyone knows how much it is (and whether it’s in px or %, etc.).
In most major browsers, the default margin is 8px on all sides. It is defined in pixels by the user-agent-stylesheet your browser provides.
Some browsers allow you to create and use your own user-agent-stylesheet, but if you are developing a website, I would recommend staying away from changing this, since your users most likely will not have a modified stylesheet and would then see a different page than you do.
If you want to change it, you can just do this:
body {
margin: 0px;
padding: 0px;
...
}
But if you have a large project and want to be more complete, use normalize.css. It resets a lot of default values to be consistent across browsers.
According to W3School's CSS reference,
the default properties and values for a body tag are,
body{ display : block; margin : 8px; }
And one can quickly get the computed details of any element by accessing the Computed Pane in the Chrome Dev tools.
css default values
https://www.w3schools.com/cssref/css_default_values.asp
body{ display : block; margin : 8px; }
* {
margin: 0;
padding: 0;
}
The body can also be reset using the asterix tag.
I have HTML tables in which checkmarks, within are used to indicate whether, say jam (column head, th) is available as (row th = flavor) grape, or strawberry.
The checkmark can be a gif, in which case the alt tag of the img tag tells a screenreader that this is a checkmark.
But suppose instead of an img, the utf-8 checkmark character is used. Does Jaws, for example, say "checkmark"?
In theory you should be able to use any UTF-8 character.
However in practice this can be "clunky" in some screen readers (reading "special character" "character name") and in some they are ignored entirely as they are assumed to be decorative. These tend to be less used screen readers, JAWS and NVDA both behave quite well.
With that being said, you are probably best using the following for how best to deal with special characters.
Is the special character purely decorative i.e. a smiley emoji - if yes hide it with <span aria-hidden="true">Your UTF-8 Character</span>.
If it isn't purely decorative, does the sentence / paragraph make sense without it? If yes, you are yet again probably best hiding it from screen readers. Or if you are willing to go the extra mile use step 3.
If the character is important / you want to offer a top notch experience for screen readers you should hide the special character as with steps 1 and 2 but then add a visually hidden span that contains the character description. An example of this is below.
One thing to note in the below example is I do not replace "checkmark" with text that says the same. Instead I replace it with the words that make most sense (which in your example was "available"). This provides the best possible experience to screen reader users.
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<p>
<span aria-hidden="true">✓</span>
<span class="visually-hidden">Available</span>
</p>
A better way for you to explore.
SVGs are likely to be a much better solution for this. They have built in semantics such as title and desc elements which you can use to expose information to screen readers.
Because they can be displayed inline you also don't have to worry about extra network calls.
If you want help on how to implement this ask another question and we can help you with that.
I've got a Squarespace website & I'm trying to increase my site width on the SKYE template so the images & content only have a small bit of padding around. Here is the link to the site - password123. I've tried this but no luck:
#page { max-width: 1300px }
I'd like the space between the nav & main content closed up too but I'm struggling with that aswell. Sorry I'm not an expert at all (obviously) any help would really be appreciated!
This can be accomplished by using CSS, inserted via the CSS Editor, to override the default style. The following CSS will decrease the space between the header and body (the .site-header bit) and will decrease the space between the body and the edges of the browser (the .responsive-padding bits).
.site-header {
padding-top: 30px;
padding-bottom: 30px;
}
.responsive-padding--right {
padding-right: 30px !important;
}
.responsive-padding--left {
padding-left: 30px !important;
}
As an aside, you can still share a link to your site with others (even for sites in trial mode) but setting your site visibility to "Password Protected" and then providing that view-only password when you provide a link. You can always change the password later if you don't want people to be able to view it going forward.
I have a form on my page with inputs and labels using correctly filled for and id attributes. After applying best practices for accessibility Chrome Lighthouse fails the tests over the use of
clip: rect(0 0 0 0)
Removing this line works fine, but it goes against the best practice for solving the issue with visible items for screenreaders/browsers.
Anyone have any idea why this happens or how to solve it?
<label for="name" class="visually-hidden">Name</label>
<input type="text" id="name">
And as for CSS
.visually-hidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
outline: 0;
appearance: none;
}
Your code satisfies success criterion 4.1.2 Name, Role, Value because the name can be programmatically determined, but fails the success criterion for 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input where label has to be visible
Note that the technique H44: Using label elements to associate text labels with form controls, clearly states:
Check that the label element is visible.
"visually hidden" hacks are not "best practice". This should be definitely banned.
People with screenreaders do not need more information than people with no screenreader : they need better information.
By hiding text from screen, you cause two damages:
people using screenreader in support would be hearing things they can't view on screen, may loose the visual focus, and become lost,
people not using screenreader will have no clue of what the field is for.
The latter is particularly damaging for people using a screen magnifier or special contrast settings where context has to be very informative.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I’ve been trying to find out various ways to manage my CSS files which become bigger and bigger as time progresses. This has a few reasons: creating websites using responsive design, plugins that require additional styling or just page-specific styling for a single element.
There are a few techniques I’m already using, like:
Creating a table of contents
Separating code into named sections (to be referred in the table of contents)
Name-spacing the elements (.home-gallery, .home-gallery-image, .home-gallery-link etc.)
Yet there’s still the issue of how to lay down the properties for each element.
Putting everything in a single line significantly decreases the readability. On the other hand, putting each and every property in a single line makes my scrollbar go sit under a shower and cry.
I’m currently experimenting with some different forms, and here’s what I came up with:
Sorting and organizing properties according to their types
Using tabulation/spacing to create a sort of table-look (captions on the left: elements; contents on the right: properties)
In an example it looks as follows:
#content-wrapper {
position: relative; top: 0; left: 0;
width: 100%; height: 200px;
color: #333; background: #fff;
}
For now it seems to me, like the only compromise between having to scroll endlessly/searching for a piece of code and making it less-readable.
So my question is: What CSS writing techniques do you use that allow for good readability and further development?
1) I define style in the order of elements in the HTML
eg: html{ } head{ } body{ } likewise in the order. So while scrolling it will be easy to locate an element for me.
2) Writing styles in the order of screen width, if media query is included. From higher screen width to lower one. Which helps me to find the styles written for media elements easily. There also I follow the first point.
3) Format styles. It is almost like you did.
4) Keeping a documentation.
sample below:
/* indented multi-selectors */
#content-wrapper
, #content-wrapper > something else {
/* alphabetic listing of properties, organizing attributes in blocks */
background-color: #fff;
border-left-width: 2px; /* column layout with blockwise different positioning */
/* separation of blocks */
color: #333;
height: 200px;
left: 0;
position: relative;
top: 0;
width: 100%;
}
probably more important than formatting and organization of individual properties is a clean structure based on conspiring classes and proper documentation, especially of the rules' sequencing (it certainly has been in my projects. often the other way round ... ;-).
imho a decent folding editor sufficiently mitigates the need of frequent scrolling. and large screens, of course.