In foundation please explain it with any good example. I couldn't understand the difference from zurb-foundation documentation.
1) hidden-for-* vs hide-for-*.
2) visible-for-* vs show-for-*.
It gave a pretty good explanation, I think, with this quote:
Adding display: none to an element will prevent screen readers from
reading it. However, there are techniques to hide content while still
making it readable by screen readers.
If I wanted to show/hide a piece of content specifically for screen readers, I would use hide-for-* and show-for-*.
hidden-for-* and visible-for-* Are for regular uses. Hiding and showing content based on screen size for all users. For example, changing the size of a header.
hide-for-* and show-for-* Are for accessibility uses. Hiding and showing content based on screen-size specifically for screen-readers. For example, changing the size of clickable buttons or showing some meta information because it would be difficult to otherwise access that information from a screen-reader.
Related
I'm having a hard time figuring out the most efficient way to resize text for mobile. I know per the documentation, making the text size responsive to the screen is fairly straightforward, simply add the is-size-*-mobile class to an element to reset the text size to the value of * (1-7) for mobile devices. What elements are the best place to do this? For example, I would like to be able to have all the text on screen change to size 7 on mobile, but so far I've had to add the is-size-7-mobile class to almost every text container on the page. While it's not impossible to do, it seems to be defeating the purpose of having such a class available through CSS.
Any tips would be greatly appreciated.
Although they lack a specific example, those Typography helpers are meant to be added to the element that holds the content you want to modify.
For example, if you want to modify the whole document consider adding it right to the body element:
<body class="is-size-7-mobile layout-documentation page-helpers">
The above example works on their documentation page you liked in your question. Just hit F12, add the modifier, and voilà, all the page changes text size.
I hear of advice of making the .hidden class not as a
.hidden { display: none }
but make it width and height of 1, and using clipping, etc, to make the element as if it still exist on screen but the content is just not visible.
But isn't it true that when we use JavaScript to hide something, the purpose of that element is done, and we want it to not show on the screen and not visible to the screen reader either?
Case 1: For example, if it is an input box, and inside the box there is a grey line of text "Enter keyword". When the user actually clicks on, or keydown, (or using the input event), now we have a JavaScript handler to hide the "Enter keyword" text, because it is just a grey prompt inside the input box. In this case, shouldn't the text be completely hidden, using in fact a display: none, so that even screen reader can't read it? (the user have learned enough to start typing, so the prompt shouldn't really still be there to be read by screen reader, right?)
Case 2: If it is a pop up bubble, for error message, or there is a link "enter your email for our subscription", and it will pop up a bubble, then when the bubble is closed, shouldn't the bubble be really closed totally using display: none? The screen reader shouldn't really still be able to read those content out for a bubble that is done and closed.
Case 3: The only case I can think of is a small fraction that the "hidden" should be available to a screen reader is: it is for a bubble for extra information, such as for the product rating (how many stars out of 5), or extra help info that can pop up when the mouse hover over some "?" icon or link. But even in this case, won't screen readers actually read out "link to more info" or "link to show rating", that is in the alt or title of the tag, and not read the pop up info until the user pops it open?
So my question is: shouldn't there be really two types of hidden. One is display: none type that screen reader shouldn't see (make it the .hidden class), and the other is width: 1px; height; 1px that the screen reader can see (or will read out) (make this the .a11y-hidden class), and whether type 2 might be far less often than type 1?
Mostly, that's it.
EDIT 2014: I switched to the clipping method from TJK at Yahoo! (because of hidden span into a link where only an <i>con is visible).
I prefer position: relative; left: -5000px over clipping 1x1px, I know that Yahoo! team only use the latter but the aim is the same.
Also I'll call it .visually-hidden (from Twenty Sth theme in WordPress and other CMS and frameworks). .a11y-hidden would mean the contrary: it's only visible (perceivable) by screen readers and in plain HTML.
Tabs content, error messages that didn't occur yet (your Case 2) shouldn't be perceived by anybody. A screen reader user will have to click on a tab to show its content as everybody else.
Note: display: none AND visibility: hidden elements will be ignored by screen readers. And also some of them (VoiceOver on OS X in particular) will ignore an element with height: 0, etc
Relevant article : Invisible Content Just for Screen Reader Users from WebAIM
Case 1: the important part being read out is the label associated with for/id to the form field.
If you use a keyboard to navigate from field to field, this text will have disappeared when you'll have focused it and it won't be visible to users that zoom at x00%. HTML5 introduced the placeholder attribute that has the same role as this prompt (this is NOT a replacement for label, this is a hint but few people read one of the HTML5 doc alas) and can still be passed to screen readers even if it's visually hidden.
Case 3: this information should be coded in HTML in an accessible manner and so you wouldn't need to visually hide information out of the viewport or in a pixel.
alt text is the preferred manner (or even better a visual with some real text by its side, while avoiding too much clutter. I've no training in ergonomics and this will often annoy webdesigners that want to remove everything from a page ;) ).
title attribute should only be used on links and you're never certain a screen reader will choose to read them. It's a personal matter and setting on a per site basis. They can be so annoyed by some sites that they'll disable these titles everywhere... Though, it's still one of the best techniques to add information if for some reason you can't do it otherwise.
How do I use this .visually-hidden class?
quick access links (to content, navigation and search input) when they don't appear in the mockup. When focused, they'll be brought to screen as in http://www.nanomatrix.fr/ (press Ctrl-L or Cmd-L, tab half a dozen times on Windows and enable tabbing through links in Safari and/or OS X. See on upper left the 3 links)
on labels when for some (bad) reason, they're not in the mockup I receive. Better have a fix (it's a good one) than doing nothing to improve accessibility when it wasn't thought of beforehand...
on captions of tables, because most of the times showing them is a no from client, external webdesigner, etc
on a span with information next to a font icon when it's coded in a performance manner but not very accessible. There are many ways of using a font icon, I'm only speaking of a few use cases
Theres a lot going on here that needs to be addressed.
Firstly, and ideally, the grey text in the input box should be handled by the 'placeholder' attribute. The browser will give the user a consistent and expected behaviour, and its also easier for you to code!
Secondly, for accessibility ideally all inputs should always have labels. This is so that the input is described correctly to screen readers. You can hide them if the design doesn't call for them (some websites only use placeholder text, but that doesn't mean they shouldn't) be there) - which brings me to my third point - hiding content on screen but not from screen readers:
{display: none} will hide information on the screen AND from screen readers. It's basically a way of making something disappear - for everyone. This is where the .visuallyhidden class (or similar) comes in - its a way of adding context (extra information) to the DOM that will be picked up by screen readers but not read by sighted users and it's a technique used very often to make pages more understandable to AT users without breaking a layout or design of a page.
Its a good idea to use a tried and trusted class, such as the one inside the HTML5 boilerplate, as getting it wrong could penalise you on Google (for trying to blackhat content) or create problems with some screen readers on some devices (e.g. iOS) - position:left and text-indent is not a good solution for a number of reasons, so stick to the 1px and clipping technique.
I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.
I am new to css.
I wanted to know which is the best standard technique to keep the page intact even when the browser size changes, the page is zoomed in or is used for any other screen size. I have tried centering my layout using a container but it gets disturbed when the page zooms in (i know it will, but all what I want is that the elements don't go out of the screen and if possible stay in almost the same position).
So what is the best and easy standard technique in css to achieve the
Thanks for your help.
The newest, cutting-edge method is called responsive web design. It's a bit complicated, but it's looking like the way to develop for multiple screen sizes. It is especially useful for small websites.
Check out some examples here: http://mediaqueri.es/
And some more in-depth information here: http://www.alistapart.com/articles/responsive-web-design/
If you set a set size for your body element anytime the browser is re-sized nothing within the page will change.
So the CSS you want to add is as follows:
body {
width: 960px; //being the size screen you want to accommodate your site to
}
Also this may help you: Commonly used pixel sizes for webpages and their pros/cons .
What are the right sizes for a webpage to be printed on A4 size paper? What other stuff should be considered?
*inline CSS is preferred in this case
Clarification: This web-page's only propose is to be printed, since it is a receipt.
Clarification # 2: This web-page is for the internal use of the company I'm working for. They would like it to look professionally designed receipt.
Clarification # 3: This web-page must be printed on one page -of A4 size- only.
Answer
I'd recommend using two different style sheets.
For viewing in the browser you could set the table width to the width of an A4 paper: 21cm. (Minus margins 18cm.)
For printing the size of the table should be "100%", which means the printer fills the whole width of the page, using the margins given by the browser's settings. (Those page margins are what makes it impossible for you to make a printout look exactly the same.)
Possibly working
Make the table narrow enough to be safe it's in the page margins. Then center that table vertically.
Solution for perfect layout
There's no way you're going to achieve that with HTML & CSS, it's just not designed to allow exact layouts!
Create PDFs online and let the users download them. Most browsers are able to render PDFs anyway.
the best way is use from #Media command in stylesheet
for example
#media print{}
use for print layout of all control and
#media screen{}
used for screen layout of control, just think you have a
<div class="wrapper">content</div>
and then in your media you should have
#media print{ .wrapper{width: 100%;background-color:Transparent;color:Black;}}
and
#media screen{ .wrapper{width: 100%;background-color:#cdebcd;color:Red;}}
with this #media you can style your layout totaly different for print and screen. you can also use
.SomeDivOrContent{visibility:hidden;display:none;}
to hide ites in print.
let me know was it helpfull or not
Like the other guys said you need to use a print CSS, but remember one thing:
display:none; //is your friend!
You can use this to make sure elements such as your navigation etc are not printed out.
By the way A List Apart has this great article on print stylesheets, check it out.
Make your printable version as simple and free from page furniture as possible.
You should create a print-specific stylesheet that as a minimum removes any width restrictions on the page so the print page can flow the text to fit the output paper.
You should also be aware that most browser don't print CSS background images by default so don't rely on them being present on the printed page.
EDIT: In answer to your comment, I would make the receipt as simple as possible. The main issue is you don't have control over the end-user's printer so you can't know for sure exactly how wide the printable area is.
Design the page using a liquid/flowable layout and try and keep it simple. Amazon's receipt style that you get in the delivery box is probably worth using for inspiration.