For Middle and High School Girl Coders: YouTube Series “My Code”

Girls Who Code, the national non-profit organization working to close the gender gap in technology, today released “My Code,” a YouTube series about learning how to code from the perspective of four female coders. The weekly series will air every Thursday on YouTube at YouTube.com/GirlsWhoCode.

“My Code” shares the experiences of four Girls Who Code alumnae: Audrey, Brittney, Margot, and Shannon. These real world role models and coders, all in high school, represent a diverse range of perspectives and interests in technology – from gaming to animation to social impact to web design. Every week, the cast of “My Code” will answer questions about what it’s like to learn to code and tackle a different perspective on their journey: from why they learned to code to the challenges they’ve faced and their plans for the future. The aim is to provide relatable and practical advice for teen girls who are interested in coding.

Reshma Saujani, Founder and CEO of Girls Who Code, said: “Teen girls increasingly take their cues about what they want to be from places like YouTube. In fact, 81.9% of US Internet users between the age of 14-17 are on YouTube. That’s a lot of teenage girls. We wanted to fill a gap we saw on YouTube and present relatable and inspiring role models for the next generation of women in technology. I often say that you can’t be what you can’t see. Our goal is to help girls see themselves as coders and, by doing so, start to close the gender gap in technology.”

Well before college, young girls have begun to opt out of computer science. While girls’ interest ebbs over time, the largest drop-off happens during the teenage years. Studies point to media portrayals of coders as “nerdy boys” and lack of roles models as key reasons that girls opt out. By college, only 18% of Computer Science majors are women. This gap then continues into the workforce and has major implications for our economy. By 2020, there will be 1.4 million open jobs in computing. Women are on track to fill just 3% of those roles.

Girls Who Code is a national non-profit organization working to close the gender gap in technology. Through its Summer Immersion Program and Clubs, Girls Who Code is leading the movement to inspire, educate, and equip young women with the computing skills to pursue 21st century opportunities. By the end of 2016, Girls Who Code will have reached 40,000 girls in every US state. Additional information is available at girlswhocode.com.

Attribute Selectors: All the Bells and Whistles

There are many types of selectors in CSS. If you’re still making your way through the darkness with nothing more than a few element selectors, a few classes, some ids, and the occasional pseudo selector, you need to find your way into the light with attribute selectors.

I wrote about Attribute Selectors in CSS back in 2008, but there are 3 new types of attribute selectors in CSS3. And they have good browser support.

Attribute Selector Basics

The basic syntax is to name an element, with an attribute in brackets following it, then give the CSS rule.

element[attribute] {
some rules here;
}

This rule, for example, would target any image with a title attribute.

img[title] {
some rules here;
}

This rule would target any anchor element with an href attribute.

a[href] {
some rules here;
}

Beyond that basic type of attribute selector, there are several operators can can be used to refine or broaden what you are selecting.

Using an equals sign, you can add specific values to the chosen attributes, making the selector even more precise. For example,

img[title="mybunny"] {
some rules here;
}

a[href="http://blogher.com"] {
some rules here;
}

The first example would select any image with the exact title attribute “mybunny.” The second would choose any link going to exactly “http://blogher.com,” but not to, say, “http://blogher.com/tech.”

The ~= operator select elements with an attribute value containing a specified word.

i [lang~="en"] {
some rules here;
}

This would match any italic element with a language attribute of English.

The |= uses the syntax |= to match hyphenated elements. This most often is used in rules targeting specific language declarations, where you might have hyphenated attributes in an HTML element such as en-US or en-GB. An example selector is:

body [lang|="en"]{
some rules here;
}

New in CSS3

The ^= operator uses the caret (^) with the equals sign to select what something begins with. It will match elements that have an attribute containing a value that starts with the specified value. For example,

a[href^="https:"] {
some rules here;
}

That selector would match only anchor elements with an href that began with https:.

The *= operator will match elements that have an attribute which contains the specified value somewhere in the attribute value. For example,

a[href*="blogher.com"] {
some rules here;
}

That would select any anchor element with an href value that contained blogher.com somewhere. This gives you a much wider sweep than the simple = operator.

Finally, the $= operator uses the dollar sign ($), which matches to elements that have a  specified value at the end. Examples:

img[src$=".gif"] {
some rules here;
}

a[href$=".doc"] {
some rules here;
}

These two examples would select only image elements ending with .gif or only href attributes ending in .doc.

Summary: How to Apply WCAG 2.0 to Mobile Devices

This slideshow requires JavaScript.

This post simply serves as a summary of the 4 posts published recently that distill the information from the W3C about how the guidelines and principles of WCAG 2.0 apply to mobile devices.

I thought it would be useful to have a single post with links to each of the previous posts. The posts take the 4 POUR principles and explain what they mean in terms of mobile application.

POUR

Mobile Accessibility and the Robust Principle

Mobile Accessibility and the Robust Principle

The W3C wants to help developers understand how WCAG 2.0 applies on mobile devices. They recently issued the first working draft on the topic. The guidelines and principles of WCAG are explained using the POUR method: Perceivable, Operable, Understandable, Robust.

In this post I will distill the W3C information on the Robust principle.

The Keyboard

Set the virtual keyboard to the type of data entry required.

Data Entry

Make data entry as easy as possible by,

  • On-screen keyboard
  • Bluetooth keyboard
  • Speech or Touch
  • Use select menus, radio buttons, check boxes or automatically enter known information (e.g. date, time, location)

Support the Platform

Don’t disable the device’s platform characteristics such as zoom, larger fonts, and captions.

Mobile device image: William Hook

Mobile Accessibility and the Understandable Principle

Mobile Accessibility and the Understandable Principle

The W3C wants to help developers understand how WCAG 2.0 applies on mobile devices. They recently issued the first working draft on the topic. The guidelines and principles of WCAG are explained using the POUR method: Perceivable, Operable, Understandable, Robust.

In this post I will distill the W3C information on the Understandable principle.

Orientation

  • Support both landscape and portrait orientations
  • Changes in orientation must be programmatically exposed to ensure detection by devices such as screen readers

Consistent Layout

  • Within a particular size and orientation, repeated items should be placed consistently
  • Consistency between different screen sizes and screen orientations is not a requirement

Positioning before the Scroll

Position important items before the scroll.

Group Operable Elements

When two elements (e.g., an icon and a text link) perform the same action, group both items within the same actionable element.

 Be Clear About Which Elements are Actionable

Actionable elements such as links or buttons should be indicated by more than one means. Use combinations of shape, color, style, positioning, text labels, and conventional iconography.

Custom Manipulations and Gestures

Provide easily accessible instructions to explain what gestures can be used to control a given interface and whether there are alternatives.

Mobile device image: William Hook

Mobile Accessibility and the Operable Principle

mobile accessibility and the operable principle

The W3C wants to help developers understand how WCAG 2.0 applies on mobile devices. They recently issued the first working draft on the topic. The guidelines and principles of WCAG are explained using the POUR method: Perceivable, Operable, Understandable, Robust.

In this post I will distill the W3C information on the Operable principle.

Touch Target Size and Spacing

  • touch targets should be at least 9 mm high by 9 mm wide
  • touch targets close to the minimum size should be surrounded by a small amount of inactive space

Touchscreen Gestures

  • Gestures should be as easy as possible to carry out and two-step gestures should be avoided
  • To prevent unintentional actions, “elements accessed via touch interaction should generally trigger an event (e.g. navigation, submits) only when the touchend event is fired (i.e. when all of the following are true: the user has lifted the finger off the screen, the last position of the finger is inside the actionable element, and the last position of the finger equals the position at touchstart).”

Device Manipulation Gestures

These suggestions are for manipulations such as shaking or tilting:

  • Developers should still provide touch and keyboard operable alternative control options
  • Provide onscreen indicators that remind people how and when to use device manipulation gestures

Button Placement

  • Place interactive elements where they can be easily reached when the device is held in different positions or by different hands
  • Flexible use is the goal

Mobile device image: William Hook

Mobile Accessibility and the Perceivable Principle

Mobile accessibility and the perceivable princple

The W3C wants to help developers understand how WCAG 2.0 applies on mobile devices. They recently issued the first working draft on the topic. The guidelines and principles of WCAG are explained using the POUR method: Perceivable, Operable, Understandable, Robust.

In this post I will distill the W3C information for the Perceivable principle.

Small Screen Size

Guidelines include:

  • Use a responsive design and minimize the amount of information that is put on each page
  • Use fewer images
  • Focus on the features needed to operate in the mobile environment
  • Use a “reasonable” default size for content and touch controls to reduce the need for zooming
  • Make sure link text does not exceed the width of the device
  • Put form fields below their labels

Zoom/Magnification

The suggestions include:

  • The user should be able to zoom to 200%. Do not block this with the page’s viewport meta element.
  • Support system fonts that follow platform level user preferences for text size
  • Support options on the page to allow the user to change text size

Contrast

Mobile device content is viewed on smaller screens and in different conditions so the allowable ratio for lessened contrast on larger text on desktop devices must be considered carefully for mobile apps. Therefore, the W3C suggestion at this point is that developers should strive to apply the lessened contrast ratio only when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size. Even then, the user must be able to zoom to magnify the text.

Mobile device image: William Hook