What if I told you web designers out there that there are people who might visit your website that don’t care what it looks like?

Visually impaired people navigate the web for the same reasons we all do, to find information, to shop and to perform a myriad of important tasks using web-based applications. But visually impaired people experience the web differently and we need to be sensitive to their needs when we design and build websites.

According to the U.S. Census Bureau and the U.N. and World Bank over 47 million Americans, and up to 650 million people worldwide, have some kind of disability. Every visitor to the sites you design needs to be able to find the information they are looking for and perform the tasks they intended to perform regardless of what the web page or app looks like. A lot of different factors that go into the creation of the web page or application can impact accessibility.

You take the blue pill–the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill–you stay in Wonderland, and I show you how deep the rabbit hole goes. — The Matrix

Are you ready to go down the accessibility rabbit hold with me? We will need to dive into to the technical aspects of web pages. HTML is the skeleton of a webpage while CSS, JavaScript and images enhance the HTML. Often times visually impaired people miss out on all these enhancements. Although accessibility is mainly a developer task, sometimes the technical requirements required to preserve or enhance accessibility will affect the appearance of the website. That means that design, copy, user experience and development all need to collaborate to make sure that navigation controls, forms, buttons, headings, buttons, links, and more are accessible.

People who are blind, visually impaired, illiterate or learning disabled use assistive technologies to navigate the Internet. Screen readers are the most common assistive technology for the web, these software programs attempt to interpret what is displayed on the web page and convey it to the user, usually through converting the text to speech but sometimes through a Braille output device. Screen magnifiers are also often used in conjunction with a screen reader. Typically a screen reader will attempt to parse the HTML from the top of the HTML file to the bottom and speak relevant elements to the user. Ideally the screen reader will allow the user to successfully move a virtual cursor down the page in order to fill out form fields, click buttons and make selections from drop-down menus and other controls.

To test thoroughly for accessibility you’ll need to ensure that the website or app performs well on each of the many screen readers available. There are several popular free and/or open source screen readers on each platform including JAWS, and NVDA. Microsoft users can use NVDA, while Apple computers and iOS devices come with Voice Over which can magnify keyboard controls and read screen contents, and for Unix devices there’s Orca. The Chrome browser has two assistive technology plugins, ChromeVox for screen reading and ChromeVis for magnification.

Most web accessibility problems occur when the screen reader’s virtual cursor becomes trapped in a poorly designed form or skips over an important control or an important piece of textual information. Verifying that websites are indeed usable is similar to browser testing because each screen reader has different requirements and limitations. This is why understanding the behavior of each screen-reader is important. The needs of various screen readers can be accommodated by adding various special HTML tags to the important elements of the page.

Modern dynamic web UI can be particularly problematic for accessibility because important elements are added to the page dynamically using JavaScript. Custom drop-down menus, modals, tooltips, accordion content and dynamic errors and notifications can be challenging for screen reader users to understand because of a communication breakdown between the HTML, JavaScript and the screen reader. Native HTML and JavaScript have no way to communicate page (Document Object Model) updates to the screen readers. Developers need to move “focus” (the screen reader’s virtual cursor) to the part of the UI that changed. When a modal opens up developers need to put the user’s focus on that modal so that the screen reader can read that content and the user can understand and interact with it.

This is done through the use of special HTML tags called WAI-ARIA tags. WAI-ARIA (Accessible Rich Internet Applications) can bridge the gaps between what the raw HTML of the page says and what sighted users see by providing a standardized way for developers to add extra meaning to states, properties, relationships, roles and live regions that a screen reader otherwise would not understand. Developers can use aria-level to explain to screen readers the hierarchy of each heading on the page. With aria-label developers can add a heading to describe the purpose of a discrete element on the page. This helps developers create clear relationships between different elements. Developers can also draw attention to important controls by labeling them with aria-role tags, for example a drop-down menu button would be labeled with the following tag: Aria-has popup: true.

See the Pen Simple Accessible Tabs by Scott Vinkle (@svinkle) on CodePen.

In the HTML in the example above the tabs are created using an unordered list with classes on each list item. The jQuery captures the click events when a tab is clicked and adds ‘aria-selected’ : ‘true’ and ‘tab-widget__tab-content—active’ to the selected tab and hides the other tabs by adding ‘aria-selected’ : ‘false’ to the remaining tabs. On line 127 the initial attributes for the tabs are set, together these snippets help screen readers recognize which tab is visible. The JavaScript on line 35 also adds keyboard support to the tabs. The rest of the file handles capturing click and keyboard events so that jQuery can add ‘role’ and ‘presentation’ attributes to the currently selected tab.

Aria tags can help screen readers to interpret custom controls as radio buttons when the custom control is labeled with: Aria-role=radio button. When an application has a sandbox area that communicates feedback or updates to the user it can be labeled with a live region tag: Aria-live. This ensures that when the text on this element changes it will automatically be spoken to the user through the screen reader.

Page refreshes are a key part of the web for screen readers because when a page refresh occurs it signals to the screen reader that it should announce the new page to the user and re-read the contents of the page to the user. This means that single page web applications pose special challenges to accessibility. In a single page app there no full page refreshes so the screen reader and therefore the user will not be alerted to the updated content. The result will be that the user receives no feedback on their actions. The best solution is to emulate native page refresh behavior. On view loaded, update the page title and announce it to the user.

The full specifications for WAI-ARIA are maintained by the W3 like the specifications for HTML itself under the Web Accessibility Initiative (WAI) but sometimes guidelines can be more helpful than specifications so here are a few general guidelines for designers:

• make sure that there is visual contrast between text and its background.
• don’t use color alone to convey information;
• provide your website with clear and consistent navigation;
• ensure that form elements clearly include associated labels;
• make sure that feedback elements like error messages can easily be identified;
• use headings and spacing to group related content;
• provide alternate text for images;
• consider designing your website so that all functionality is accessible through the keyboard.

There are several simple decisions you can make when developing a website that will make the website more accessible without getting too deep in special accessibility markup or screen reader testing. By making sure that your HTML conveys meaning through its structure you will help screen readers process information in the same way it appears on the page for sighted users. This is important for users who use a magnifier in conjunction with a screen reader.

Using appropriate HTML mark-up for headings, lists, tables, and other elements allows the screen reader to categorize the structure of the page for the user in a familiar way. For more involved layouts HTML5 provides additional elements, such as

React is one of today’s most popular ways to create a component-based UI. It helps to organize an application into small, human-digestible chunks. With its “re-render the whole world” approach, you can avoid any complex internal interactions between small components, while your application continues to be blazingly fast due to the DOM-diffing that React does under the hood (i.e. updating only the parts of the DOM that need to be updated).

But can we apply the same techniques to web graphics — SVG in particular? Yes! I don’t know about you, but for me SVG code becomes messy pretty fast. Trying to grasp what’s wrong with a graph or visualization just by looking at SVG generator templates (or the SVG source itself) is often overwhelming, and attempts to maintain internal structure or separation of concerns are often complex and tedious.

The post Generating SVG With React appeared first on Smashing Magazine.

Spec Pizzas. Need I say more? The absurdity is so obvious that it is hard to understand why thoughts of spec work being positive prevail. I have never done that. And as much as these pizza guys will never visit that potential customer again I want to encourage you that you also walk away from people who show no respect for your professionality. No money, no cookies. (Or pizza, for that matter.)

By the way, we have more cartoons for you here.

Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.

Design Trend: How to Create a Cool Split Screen Aesthetic

The 4 Top Colour Trends for 2016

Design for Startup

Ultimate Guide to Font Pairing

Google Blocky – The Web-based Visual Programming Editor

FontPro – Typography Project Made Simple

I’m not a Talented Designer

The Very Best of Material Design in 2015

The Galaxy of ‘Star Wars’ Fonts

Being Responsive to the Small Things

Grid, Flexbox, Box Alignment: Our New System for Layout

The 10 Chrome Extensions You Need Most

Juntoo – Add Notes to any Element on any Web Page

How Advertising Taught Me Good Design

Brands that Won (and Lost) Google in 2015

Ad Blocking Phase II

National Geographic Release its Pictures of 2015

The New York Times: The Year in Visual Stories and Graphics

Google Trends – Exlore the Biggest Moments of 2015

Miss Universe: A Case Study on Banner Blindness in Print Design

The 15 Most Beautifully Designed Apps of 2015

Responsive Images Now Landed in WordPress Core

The State of the Modern Political Logo

I Analyzed 250 SaaS Pricing Pages – Here’s What I Found

Complete Beginner’s Guide to Information Architecture

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

LAST DAY: Libertad, 14 Unique Fonts in 1 Versatile Sans-Serif Font – only $14!

Source

The following is a guest post by Manuel Matuzovic. It illustrates how flex-grow works, weird quirks and all. Then he goes into several examples on how common layout patterns may be implemented using flex-grow and flex-basis.

When I found out about flex-grow, I made a simple demo to find out what it did and how it worked.
I thought I got everything figured out, but when I tried it on a website a colleague has recently made, nothing worked as expected. No matter what we did, the layout didn’t look and work like it did in my demo. That got me thinking and I started to doubt that I knew what flex-grow was all about.

How flex-grow doesn’t work

Before we are going to take a deep dive into the functionality of flex-grow, I want to explain to you what I got wrong at first.

I thought that all flex items with flex-grow set to 1 would have an equal width. If one of the items had flex-grow set to 2 that item would be twice as big as all the others.

This sounds great. It seems as if this is exactly what’s happening in the Pen I mentioned before. The parent element is 900px wide, the section with flex-grow: 2 has a calculated width of 600px and the aside element with flex-grow: 1 has a calculated width of 300px.

As you can see, everything works out perfectly in this demo, but it did not work at all in a real life example, even though we used the exact same CSS. As it turns out, the problem wasn’t the CSS, but the content (or lack of content). The demo I made works, because by only using two empty elements I created a test case that was too simple to depict the important specifics of the property.

How flex-grow really works

I just described how flex-grow does not work, but I showed you a demo that actually does do what I claim it does not (Later on in this article I will explain the reason for this.).

To clarify things, let me show you another Pen. We have got the exact same setup as in the first pen, but this time the section and aside elements aren’t empty. Now the ratio isn’t 2:1 anymore and the element with flex-grow set to 1 is actually bigger than the element with flex-grow set to 2.

Explanation

If we apply display: flex; to the parent element and don’t change anything else, the child elements will be stacked horizontally, no matter what. If there isn’t enough space, they will shrink in size. If on the other hand there is more than enough space, they won’t grow, because Flexbox wants us to define how much they should grow. So rather than telling the browser how wide an element should be, flex-grow determines how the remaining space is distributed amongst the flex items and how big the share is each item receives.

Or in other words:

A flex container distributes free space to its items (proportionally to their flex grow factor) to fill the containers, or shrinks them (proportionally to their flex shrink factor) to prevent overflow.

https://drafts.csswg.org/css-flexbox/#flexibility

Demonstration

The concept is much easier to understand if we visualise it.

First we set the display property of our parent element to flex and by doing that our child elements become flex items and are positioned horizontally next to each other.

Next we decide how many shares of the extra space each element receives. In our previous example the first element receives 2/3 of the remaining space (flex-grow: 2) and the second element 1/3 (flex-grow: 1). By knowing how many flex-grow values we have in total, we know by which number to divide the remaining space.

Finally we have the number of distributable pieces. Each element receives the appropriate number of pieces based on its flex-grow value.

Calculation

Theory and visual representations are nice, but let’s get dirty and do the math for the above example.

For our calculation we need 4 numbers: The parent width, the initial width of our section and our aside element and the total number of flex-grow values we’ll use.

parent width: 900px
section width: 99px
aside width: 623px
total flex-grow values: 3

1. First we have to calculate the remaining space

That’s pretty easy. We take the parents width and subtract the total initial width of every child element.

900 - 99 - 623 = 178

parent width – initial section width – initial aside width = remaining space

2. Next we have to determine how much one flex-grow is

Now that we have the remaining space we need to determine into how many slices we want to cut it. The important thing here is that we don’t divide the remaining space by the number of elements, but by the number of total flex-grow values. So in our case that’s 3 (flex-grow: 2 + flex-grow: 1)

178 / 3 = 59.33

remaining space / total flex-grow values = “one flex-grow”

3. Finally the sliced up remaining space gets distributed between all elements

Based on their flex-grow values the section receives 2 slices (2 * 59.33) and the aside 1 (1 * 59.33). These numbers are added to the initial width of each element.

99 + (2 * 59.33) = 217.66 (≈218px)

initial section width + (section flex-grow value * “one flex-grow”) = new width

and

623 + (1 * 59.33) = 682.33 (≈682px)

initial aside width + (aside flex-grow value * “one flex-grow”) = new width

Easy cheesy, right?

Alright, but why does the first demo work?

We have the formula, now lets find out why we actually got the numbers we wanted in the first Pen even though we didn’t know what we were doing.

parent width: 900px
section width: 0px
aside width: 0px
total flex-grow values: 3

1. Calculate the remaining space

900 - 0 - 0 = 900

2. Determine how much one flex-grow is

900 / 3 = 300

3. Distribute the sliced up remaining space

0 + (2 * 300) = 600  
0 + (1 * 300) = 300

If the width of each element is 0, the remaining space equals the actual width of the parent element and thus it looks like flex-grow divides the parent element’s width in proportional parts.

flex-grow and flex-basis

Just a quick recap: flex-grow will take the remaining space and divide it by the total amount of flex grow values. The resulting quotient is multiplied by the respective flex-grow value and the result is added to each child elements initial width.

But what if there’s no remaining space or what if we don’t want to rely on the elements initial width, but on a value we set? Can’t we still use flex-grow?

Of course we can. There is a property called flex-basis which defines the initial size of an element. If you use flex-basis in conjunction with flex-grow the way the widths are calculated changes.

This component sets the flex-basis longhand and specifies the flex basis: the initial main size of the flex item, before free space is distributed according to the flex factors.

https://drafts.csswg.org/css-flexbox/#valdef-flex-flex-basis

The big difference if we apply flex-basis to an element is that we don’t use its initial width in our calculation anymore, but the value of its flex-basis property.

I have adapted our previous example by adding flex-basis to each element. Here’s the Pen for you.

parent width: 900px
section width: 400px (flex-basis value)
aside width: 200px (flex-basis value)
total flex-grow values: 3

1. Calculate the remaining space

900 - 400 - 200 = 300

2. Determine how much one flex-grow is

300 / 3 = 100

3. Distribute the sliced up remaining space

400 + (2 * 100) = 600  
200 + (1 * 100) = 300

Just for the sake of completeness, you don’t have to use pixel values and hope for the best, percentages work as well.

Working with the box model

So to cover everything, let’s check out what happens if we add padding and margin. Nothing too special actually. In the first step of the calculation you just have to remember to subtract the margins as well.

The only thing to note is that in terms of box-sizing flex-basis behaves like the width property. That means that the calculation as well as the results change if the box-sizing property changes. If box-sizing was set to border-box, you would only work with the flex-basis and margin values in your calculation, because the padding is already included in the width.

Some useful examples

Alright, enough with the math. Let me give you some examples of how you’re able to establish flex-grow effectively in your projects.

No more width: [ x ]%

Due to the fact that the remaining space gets distributed automatically, we don’t need to think about width values anymore, if we want our child elements to fill the parent element.

See the Pen QyWEBb by Manuel Matuzovic (@matuzo) on CodePen.

The “Holy Grail” 3 column liquid layout with pixel-widths

Mixing fixed and fluid widths in column layouts is possible with float, but it is neither intuitive or easy nor flexible. Of course with Flexbox and a little flex-grow and flex-basis magic that is a piece of cake.

See the Pen jbRjMG by Manuel Matuzovic (@matuzo) on CodePen.

Filling remaining space with any element

If you, for example, have an input field next to a label and you want the input field to fill the rest of the space, you don’t need ugly hacks anymore.

See the Pen eJYdWV by Manuel Matuzovic (@matuzo) on CodePen.

You can find more examples on Philip Waltons Solved by Flexbox.

Listening to the specs

According to the specs, we should use the flex shorthand rather than flex-grow directly.

Authors are encouraged to control flexibility using the flex shorthand rather than flex-grow directly, as the shorthand correctly resets any unspecified components to accommodate common uses.

https://drafts.csswg.org/css-flexbox/#flex-grow-property

But be careful! If you just use flex: 1; some of the above examples won’t work anymore, because the values set for the common uses don’t equal the default values and thus interfere with our needs.

If you want to use flex for our use case, you should define it like this:

flex: 2 1 auto;  /* (<flex-grow> | <flex-shrink> | <flex-basis>) */

Learning Flexbox

If you want to learn more about Flexbox, please check out these great resources:

• A Complete Guide to Flexbox by Chris Coyier
• Flexbox adventures by Chris Wright
• Flexbox Froggy by Thomas Park
• What the Flexbox? by Wes Bos
• flexboxin5
• Flexbox Tester by Mike Riethmuller

Summary and lessons learned

Is flex-grow weird? Nah, not at all. We just have to understand how it works and what it does. If an element has flex-grow set to 3 it does not mean that it’s 3 times bigger than an element that has flex-grow set to 1, but it means that it gets 3 times more pixels added to its initial width than the other element.

I learned my lesson by testing flex-grow with two empty elements, which gave me a completely different understanding of what the property actually does and this of course led to wrong conclusions. You should check out new stuff in an environment that is as realistic as possible, to get the best impression of how it really works and behaves.

`flex-grow` is weird. Or is it? is a post from CSS-Tricks

Today, those that want to integrate video and audio files in a website, rely on HTML5. Plyr is an extensive tool to help with that, allowing you to create a custom interface for HTML5 video and audio. As Plyr is a contemporary piece of web technology, it is both responsive and accessible.

Simple Operation, Freely Configurable

Coming to results with the Plyr is easy. There are three files: a JavaScript, a stylesheet and an SVG file. The JavaScript and the stylesheet file need to be implemented in the HTML document. They are responsible for the functionality and the appearance of the user interface. The icons of the function buttons are available as SVG sprites and are tied in via the stylesheet file.

The markup of the videos and audios is done by using their respective HTML5 elements, as usual. An additional „

<div class="player">
  <video poster="film.jpg"controls>
    <source src="film.mp4"type="video/mp4">
    …
  </video>
</div>

plyr.setup({
  controls: ["play", "volume"],
  i18n: {play: "Get it going", volume: "Let's get loud"}
})

<div data-video-id="L1h9xxCU20g"data-type="youtube"></div>

document.querySelectorAll(".player")[0].plyr.pause();

Comics of the week #319

December 26th, 2015 admin No comments

Every week we feature a set of comics created exclusively for WDD.

The content revolves around web design, blogging and funny situations that we encounter in our daily lives as designers.

These great cartoons are created by Jerry King, an award-winning cartoonist who’s one of the most published, prolific and versatile cartoonists in the world today.

So for a few moments, take a break from your daily routine, have a laugh and enjoy these funny cartoons.

Feel free to leave your comments and suggestions below as well as any related stories of your own…

Medically speaking

It’s a one to one ratio

Where’s the concession stand?

Can you relate to these situations? Please share your funny stories and comments below…

Easily Rename Multiple Photoshop Layers with the Renamy – only $7!

Source

Categories: Designing, Others Tags: