Tag: Accessibility

Five 5-minute Videos from Ethan on Design & Accessibility

Ethan:

I’ve been working with Aquent Gymnasium to produce a series of five short tutorial videos, which have been launching over the course of this past week. Since the last video just went live, I’m thrilled to share the whole list with you:

Introduction to using VoiceOver on macOS
Designing beautiful focus states
Flexible and accessible typesetting
Responsively designing with viewport units
Designing beautiful and accessible drop caps

Five minutes is a real sweet spot for a how-to video. Ain’t no time to screw around. I loved every minute of these.

Direct Link to ArticlePermalink

The post Five 5-minute Videos from Ethan on Design & Accessibility appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,

Accessibility Links

Austin Gil has kicked off the first in a five-part series about “HTML Forms Right” and to starts with semantics. It’s talking to the “we build our front-ends with JavaScript” crowd. The first block of code is an example of an Ajax form submission where the data submitted is gathered through the JavaScript API FormData.

Why is that so vital? Well, no <form> tag, no FormData. Why else use a form (aside from the Enter-key submission):

“But Austin, I’m building an SPA. Therefore if the user even sees the form, it means JavaScript MUST be enabled.” And you’d be right. Although, if it is an important form, you may want to consider supporting a no-JS world. The day may come that you want to implement SSR.

Server-Side Rendering (SSR) is going to get easier and easier to do as the benefits of it become more and more obvious. Google tells us a page that is client-side rendered has week-long-ish queue to get indexed and re-indexed on changes. Not to mention SSR is almost definitely going to be far faster to load.


Oscar Braunert’s Inclusive Inputs is a nice follow-up read as it begins with form HTML that is so close to being right, but is painfully not right. (Hint: it’s missing the label/input connection). Then he gets into interesting patterns like how to accessibly mark up required fields and fields with errors. Like:

<div class="form-group">   <label for="password">     Password     <span class="required" aria-hidden="true">*</span>     <span class="sr-only">required</span>   </label>   <input      type="password"     id="password"     name="password"     aria-describedby="desc_pw"   >   <p class="aside" id="desc_pw">Your password needs to have at least eight characters.</p> </div>

Amber Wilson gets into Accessible HTML elements with the twist of avoiding any ARIA usage at all:

You may be aware that ARIA roles are often used with HTML elements. I haven’t written about them here, as it’s good to see how HTML written without ARIA can still be accessible.

Shout out to <dl>.


Sarah Higley does get into ARIA in Roles and relationships, but she warns us to be very careful upfront:

[…] a budding accessibility practitioner might find themselves experimenting with more serious roles like menulistbox, or even treegrid. These are tantalizing, powerful patterns that allow you to create experiences that are not supported by only vanilla HTML. Unfortunately, they are also brittle; even small mistakes in using these roles can take a user on a very bad trip.

Talk to your kids about ARIA before it’s too late.

Ideally, don’t use ARIA at all. But if the accessibility is screwed up to the point it can’t be fixed at the DOM level, Sarah gets into some tricks. For example, one uses role="presentation" to essentially remove an element’s default role (when it is in the way).


Speaking of ARIA and not using it unless you have to, one of the things you can do with ARIA is label controls. Adrian Roselli has thoughts on how best to do that:

Here is the priority I follow when assigning an accessible name to a control:

1. Native HTML techniques
2. aria-labelledby pointing at existing visible text
3. Visibly-hidden content that is still in the page
4. aria-label

The post Accessibility Links appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

15 Things to Improve Your Website Accessibility

This is a really great list from Bruce. There is a lot of directly actionable stuff here. Send it around to your team and make it something that you all go through together.

Here’s a little one that prodded me to finally fix…

Most screen readers allow the user to quickly see a list of links on a page [..] However, if every link has text saying “Click here” or “Read more”, with nothing else to distinguish them, this is useless. The easiest way to solve this is simply to write unique link text, but if that isn’t possible, you can over-ride the link text for assistive technology by using a unique aria-label attribute on each link.

I had links like that right here on CSS-Tricks. Some of them are automatically created by WordPress itself, not something I hand-coded into a template. When you show the_excerpt of a post, you get a “read more” link automatically, and aside from getting your hands dirty with some filters, you don’t have that much control over it.

DevTools showing the DOM of a "read more" link with no context.

Fortunately, I already use a cool plugin called Advanced Excerpt. I poked into the settings to see if I could do something about injecting the post title in there somehow. Lookie lookie:

A setting for Advanced Excerpt that does screen reader links.

That screen-reader-text class is exactly what I already used for that kind of stuff, so it was a one-click fix!

Much nicer DOM now for those links:

Direct Link to ArticlePermalink

The post 15 Things to Improve Your Website Accessibility appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Understanding Web Accessibility Color Contrast Guidelines and Ratios

What should you do when you get a complaint about the color contrast in your web design? It might seem perfectly fine to you because you’re able to read content throughout the site, but to someone else, it might be a totally different experience. How can put yourself in that person’s shoes to improve their experience?

There are some relatively easy ways to test contrast. For example, you can check the site on your phone or tablet in bright sunlight, or add a CSS filter to mimic a grayscale view). But… you don’t have to trust your eyes. Not everyone has your exact eyes anyway, so your subjective opinion can possibly be a faulty measurement. 

You can mathematically know if two colors have enough contrast between them. 

The W3C has a document called Web Content Accessibility Guidelines (WCAG) 2.1 that covers  successful contrast guidelines. Before we get to the math, we need to know what contrast ratio scores we are aiming to meet or exceed. To get a passing grade (AA), the contrast ratio is 4.5:1 for most body text and 3:1 for larger text. 

How did the W3C arrive at these ratios?

The guidelines were created for anyone using a standard browser, with no additional assistive technology. The contrast ratios that the WCAG suggests were based initially on earlier contrast standards and adjusted to accommodate newer display technologies, like antialiased text, so content would be readable by people with a variety of visual or cognitive difficulties, whether it be due to age, sickness, or other losses of visual acuity.  

We’re basically aiming to make text readable for someone with 20/40 vision, which is equivilent to the vision of someone 80 years old. Visual acuity of 20/40 means you can only read something at 20 feet away that someone with perfect 20/20 vision could read if it was 40 feet away.

So, say your design calls for antialiased text because it looks much smoother on a screen. It actually sacrifices a bit of contrast and ding your ratio. The WCAG goes into more detail on how scoring works.

There are other standards that take contrast in consideration, and the WCAG used some of these considerations to develop their scoring. One is called the Human Factors Engineering of Computer Workstations (ANSI/HFES 100-2007) was published in 2007 and designated as an American standard for ergonomics. It combined and replaced two earlier standards that were created by separate committees. The goal of the combined standard was to accommodate 90% of computer users, and cover many aspects of computer use and ergonomics, including visual displays and contrast. So, that means we have physical screens to consider in our designs.

What does the ratio mean?

The contrast ratio explains the difference between the lightest color brightness and the darkest color brightness in a given range. It’s the relative luminance of each color.

Let’s start with an egregious example of a teal color text on a light gray background. 

<h1>Title of Your Awesome Site</h1>
h1 {   background-color: #1ABC9C;   color: #888888; }
Yikes!

It’s worth calling out that some tools, like WordPress, provide a helpful warning for this when there’s a poorly contrasted text and background combination. In the case of WordPress, a you get notice in the sidebar.

“This color combination may be hard for people to read. Try using a brighter background color and/or a darker text color.”

“OK,” you say. “Perhaps you think that teal on gray color combination is not exactly great, but I can still make out what the content says.“ (I’m glad one of us can because it’s pretty much a muddy gray mess to me.)

The contrast ratio for that fine piece of hypertext is 1.47:1.

I wanted a better understanding of what the contrast scores were actually checking and came to find that it requires the use of mathematics… with a side of understanding the differences between human and computer vision.  This journey taught me about the history of computer vision and a bit about biology, and gave me a small review of some math concepts I haven’t touched since college.

Here’s the equation:

(L1 + 0.05) / (L2 + 0.05)
  • L1 is the relative luminance of the lighter of the colors.
  • L2 is the relative luminance of the darker of the colors.

This seems simple, right? But first we need to determine the relative luminance for each color to get those variables.

OK, back to relative luminance

We mentioned it in passing, but it’s worth going deeper into relative luminance, or the relative brightness of any color expressed into a spectrum between 0 (black) and 1 (white).

To determine the relative luminance for each color, we first need to get the RGB notation for a color. Sometimes we’re working with HEX color values and need to covert that over to RGB. There are online calculators that will do this for us, but there’s solid math happening in the background that makes it happen. Our teal hex color, #1ABC9C, becomes an RGB of 26, 188, 156.

Next, we take each value of the RGB color and divide each one by 255 (the max integer of RGB values) to get a linear value between 0 and 1. 

So now with our teal color it looks like this:

Component Equation Value
Red 26/255 0.10196078
Green 188/255 0.73725490
Blue 156/255 0.61176471

Then we apply gamma correction, which defines the relationship between a pixel’s numerical value and its actual luminance, to each component part of the RGB color. If the linear value of a component is less than .03938, we divide it by 12.92. Otherwise, we add .055 and divide the total by 1.055 and take the result to the power of 2.4.

Our gamma corrected color components from our teal color end up like this:

Component Equation Value
Red ((0.10196078 +.055)/1.055) ^ 2.4 0.01032982
Green ((0.73725490 +.055)/1.055) ^ 2.4 0.50288646
Blue ((0.61176471 +.055)/1.055) ^ 2.4 0.33245154

This part of our equation comes from the formula for determining relative luminance.

We just sort of sped past gamma correction there without talking much about it and what it does. In short, it translates what a computer “sees” into the human perception of brightness. Computers record light directly where twice the photons equals twice the brightness. Human eyes perceive more levels of light in dim conditions and fewer in bright conditions. The digital devices around us make gamma encoding and decoding calculations all the time. It’s used to show us things on the screens that match up to our perception of how things appear to our eyes.

Finally, we multiply the different colors by numbers that signify how bright that color appears to the human eye. That means we determine the luminance of each color by multiplying the red component value by .2126, the green component value by .7152, and the blue component by .0722 before adding all three of those results together. You’ll note that green gets the highest value here,

So, one last time for teal:

Component Equation Value
Red 0.01032982  X 0.2126 0.00219611973
Green 0.50288646  X 0.7152 0.35966439619
Blue 0.33245154  X 0.0722 0.02400300118

…and add them together for luminance!

L1 = 0.00219611973 + 0.35966439619 + 0.02400300118 = 0.38586352

If we do the same to get our L2 value, that gives us 0.24620133.

We finally have the L1 and L2 values we need to calculate contrast. To determine which value is  L1 and and which is L2 , we need to make sure that the larger number (which shows the lighter color) is always L1 and is divided by the smaller/darker color as L2.

Now compare that result with the WCAG success criterias. For standard text size, between 18-22 points, a minimul result of 4.5 will pass with a grade of AA. If our text is larger, then a slightly lower score of  3 will do the job. But to get the highest WCAG grade (AAA), we have to have a contrast ratio result of at least 7. Our lovely combination fails all tests, coming far under 4.5 for regular text or 3 for headline style text. Time to choose some better colors!

I’m so glad we have computers and online tools to do this work for us! Trying to work out the details step-by-step on paper gave me a couple weeks of frustration. It was a lot of me getting things wrong when comparing results to those of automated contrast checkers.

Remember how teachers in school always wanted you to show your math work to prove how you got to the answer? I made something to help us out.

If you view this demo with the console open, you’ll see the math that goes into each step of the calculations. Go ahead, try our two example colors, like #1ABC9C and #888888.

I just want my page to have proper contrast, what do I do?!

There are a variety of accessibility resources that you can can audit your site. Here’s a list I put together, and there’s another list here on CSS-Tricks.

But here are a few tips to get you started.

First, identify areas that are not serving your accessibility needs.

The WAVE accessibility tool is a good place to start. Run your site through that and it will give you contrast results and help identify trouble areas.

Yay, passing scores!

Follow the suggestions of the audit

Use best practices to improve your scores, and remove the errors. Once you identify contrast errors, you can try out some different options right there in the WAVE tool. Click on the color box to pop open a color picker. Then play around until the errors go away, and you’ll know what you can replace in your code.

Run the test again

This way, you can make sure your changes improved things. Congratulations! You just made your product better for all users, not just ones affected by the accessibility errors!

What comes next is up to you!

You can make it easier on yourself and start all new products with the goal of making them accessible. Make accessibility guidelines part of your requirements for both technology and design. You’ll save yourself potentially hundreds of hours of remediation, and potential legal complaints. U.S. government and education websites are required to comply, but other industries are often taken to task for not making their sites equally available for all people.

If you have the option, consider using established and tested frameworks and web libraries (like Bootstrap or Google’s Material Design) that have already figured out optimum contrast theme colors. In many cases, you can take just what you need (like only the CSS) or at least review their color palettes to inform choices. You should still check the contrast though because, while most standard text options in a framework may follow contrast ratio WCAG suggestions, things like alert and message styles may not. (I’m looking at you, Bootstrap!)

Derek Kay has reviewed a list of web frameworks with a focus on accessibility, which I suggest you read if you are looking for more options. The U.S. Web Design System shows one way to solve color/contrast puzzles using their CSS token system that labels colors to make contrast differences super clear), but they also link to several very good resources for improving and understanding contrast.

We took a deeper dive here than perhaps you ever really need to know, but understanding what a contrast ratio is and what it actually means should help you remember to keep contrast in mind when designing future sites, web apps, and other software.

Having a clearer understanding of what the contrast ratio means helps me to remember who poor contrast can affect, and how to improve web and mobile products overall.

I’m not the ultimate subject expert on contrast, just a very, very curious girl who sometimes has issues reading things on the web with low contrast.

If you have any additional thoughts, corrections or further research to share, please leave a comment and I’ll amend this article! The fuller our understanding of the needs and requirements of our sites is, the better we can plan improvements and ultimately serve the needs of our audiences.

The post Understanding Web Accessibility Color Contrast Guidelines and Ratios appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

Bad accessibility equals bad quality

Here’s a smart post from Manuel Matuzovic where he digs into why accessibility is so important for building websites:

Web accessibility is not just about keyboard users, color contrast or screen readers. Accessibility is a perfect indicator for the quality of a website. Accessibility is strongly interlocked with other areas of web design and web development. If your website is accessible, it usually means that it’s inclusive, resilient, usable, it offers great UX for everyone, and it’s fast.

I love this idea: that you can’t have a good UI that isn’t also accessible and how accessibility, performance, and quality are all intermingled with one another. Actually, this has me thinking… I’ve never worked on a project where either of these things are the problem in isolation. It’s all of them, always.

Direct Link to ArticlePermalink

The post Bad accessibility equals bad quality appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Debunking the Myth: Accessibility and React

I find it notable when the blog of a major accessibility-focused company like Deque publishes an article called Debunking the Myth: Accessibility and React. Mark Steadman is essentially saying if a site has bad accessibility, it ain’t React… it’s you. The tools are there to achieve good accessibility.

React didn’t use a <div> for a <button>, but you did. React didn’t force extra markup all over the page when you decided to not use a Fragment. React didn’t forget to change the title of the page, because that was something you neglected.

Is it different how you have to do it in React versus how you have to do it in some other framework or CMS? Yes, it is. Different, but neither worse nor harder.

I’m optimistic that well-made React components focused on accessibility can have a positive impact on the web. Just today I was pair programming and looking at some HTML for a toggle UI in a Rails template. It had a little bug we wanted to fix, which required an HTML change. But this toggle wasn’t a component, it was a chunk of HTML used in dozens of places on the site. Gosh, did I wish this part of the site was architected with proper components instead, a practice that all JavaScript frameworks endorse?

Where did the bad wrap on React come from? Well, we could debate that for days. Is it that JavaScript-focused developers never got the HTML training they needed? Maybe. Was it gnarly, unsemantic React code that was written early on that others copy and pasted too many times? Maybe. I’m not sure we’ll ever know. The important thing is that we all do a better job now.

Direct Link to ArticlePermalink

The post Debunking the Myth: Accessibility and React appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Growing Accessibility Conversations

I started this year on a new path at Knowbility — to help people and organizations create accessible content and apps. But what was exciting and helped motivate me more were two things:

  1. WebAIM’s Accessibility Analysis of One Million Page Homepages. With over 97% of sites having WCAG failure of some kind, it’s a stinging indictment on our industry. There’s a lot of work to be done — that means outreach and education, helping other developers incorporate accessibility into their workflows, coding pull requests with accessibility fixes, making certain components for design systems are accessible and much more.
  2. The Supreme Court of the United States rejecting Domino’s appeal. The Supreme Court leaves the Ninth Circuit federal appeals court’s ruling, which means that people with disabilities who have trouble with sites or apps that are not accessible can bring claims under the Americans with Disabilities Act (ADA). This result means that organizations can’t kick the proverbial can down the road for making their apps and products accessible.

In regards to the One Million Pages, I noticed that web designers and developers outside of accessibility circles discussing accessibility with a sustained focus I hadn’t witnessed before.

And I would have conversations with people outside web design and development altogether about accessibility due to this court case alone. Companies and organizations were watching it very closely.

This added increased awareness from both WebAIM’s report and the Domino’s appeal has helped fuel the discussion, making it easier to keep the conversation going to make digital accessible to all.

The post Growing Accessibility Conversations appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Automated (and Guided!) Accessibility Audits with axe Pro

It’s important to know there are tools for automated accessibility testing of websites. They are a vital part in helping make sure your website is usable for everyone, which is both a noble goal and damn good for business. Automated tests won’t catch every potential accessibility issue, but they help a great deal, and in my experience, help establish a culture of caring about accessibility. The more seriously you take these tests and actually fix the problems, the more likely it is you’re doing a good job of accessibility overall.

There is one testing tool that stands above the rest, axe (it’s even what Google’s Lighthouse uses), and now it’s gotten a whole lot better with axe Pro.

The axe extention is still the powerhouse, where robust accessibility reports are a click away in DevTools:

axe in Chrome DevTools

But there’s more!

Guided Question-Answer Accessibility Walkthroughs

Not to bury the lede, this is probably the best new feature of axe Pro. The tool is so friendly, it gives accessibility testing powers to just about anybody:

“Axe Pro essentially lets every developer function as an in-house accessibility expert,” says Preety Kumar, CEO of Deque Systems.

Run the tests, and it just asks you stuff in plain English.

Screenshot of axe asking me if the page title is correct on this page
Anybody can answer questions from a guided tour like this. It’s extremely helpful to be hand-held through thinking about these important aspects of your site.

For example, here’s a test walkthrough of it helping me think about header and header levels:

Step 1: start test
Step 2: Identify headers that shouldn't be.
Step 3: Identify elements that should be headers but aren't.

First, you identify the problems, then you can save the information so you can work on the fixes as you can.

Your tests can be saved as online reports

Working in DevTools is nice and the perfect place to be digging into the accessibility issues on your site. But that session in DevTools is short-lived! It’s just one developer working on one computer at one point in time. With the new axe Pro web dashboard, you can save your tests online. This is useful for a variety of reasons:

  • You can save your testing so far and come back to it later to keep going.
  • You can clear out tests and re-do them, to track your progress moving forward.
  • You can have multiple tests on the dashboard to help you test multiple pages and projects.
  • Your team has a home to manage these tests all together.

You can export the data

If you’d prefer to get the results out of axe and somewhere else, you can now export the data as JSON or CSV. Perhaps you want to track the results over time to visualize improvements or port the information to some other tool. The data is yours.

export dialog box for axe test results

I found helpful prompts immediately.

I’d like to think I care about accessibility and work accessibily as I go, but if you’re anything like me, you’ll find mistakes find their way into your code bases over time. Just like we might have automated tools to watch our performance metrics over time, we can and should be regularly testing accessibility, especially when automation helpfulness like axe Pro provides.

Just in playing with axe Pro for a few hours, I’ve…

  • Found many images that had missing and incorrect alt text on them.
  • Found a few elements that were using header tags that really shouldn’t have been.
  • Fixed some color contrast on some elements that were just barely not AA and light tweaks got them there.

That second one I found very satisfying as the guided tour helped me find them. That’s something an entirely automated tool won’t really help find, it requires you looking at things and making judgment calls.

I’m very optimistic this is going to help lots of folks unearth accessibility issues they wouldn’t have caught otherwise.

It’s free for a limited time

It’s kind of a big deal:

Developers can typically identify about half of all critical accessibility blockers through axe.

You might as well try it out!

The post Automated (and Guided!) Accessibility Audits with axe Pro appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Improving Video Accessibility with WebVTT

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
– Tim Berners-Lee

Accessibility is an important element of web development, and with the ever-growing prevalence of video content, the necessity for captioned content is growing as well. WebVTT is a technology that solves helps with captioned content as a subtitle format that integrates easily with already-existing web APIs.

That’s what we’re going to look at here in this article. Sure, WebVTT is captioning at its most basic, but there are ways to implement it to make videos (and the captioned content itself) more accessible for users.

See the Pen
VJJMZz
by Geoff Graham (@geoffgraham)
on CodePen.

Hi, meet the WebVTT format

First and foremost: WebVTT is a type of file that contains the text “WebVTT” and lines of captions with timestamps. Here’s an example:

WEBVTT  00:00:00.000 --> 00:00:03.000 - [Birds chirping] - It's a beautiful day!  00:00:04.000 --> 00:00:07.000 - [Creek trickling] - It is indeed!  00:00:08.000 --> 00:00:10.000 - Hello there!

A little weird, but makes pretty good sense, right? As you can see, the first line is “WEBVTT” and it is followed by a time range (in this case, 0 to 3 seconds) on Line 3. The time range is required. Otherwise, the WEBVTT file will not work at all and it won’t even display or log errors to let you know. Finally, each line below a time range represents captions contained in the range.

Note that you can have multiple captions in a single time range. Hyphens may be used to indicate the start of a line, though it’s not required and more stylistic than anything else.

The time range can be one of two formats: hh:mm:ss.tt or mm:ss.tt. Each part follows certain rules:

  • Hours (hh): Minimum of two digits
  • Minutes (mm): Between 00 and 59, inclusive
  • Seconds (ss): Between 00 and 59, inclusive
  • Milliseconds (tt): Between 000 and 999, inclusive

This may seem rather daunting at first. You’re probably wondering how anyone can be expected to type and tweak this all by hand. Luckily, there are tools to make this easier. For example, YouTube can automatically caption videos for you with speech recognition in addition to allowing you to download the caption as a VTT file as well! But that’s not it. WebVTT can also be used with YouTube as well by uploading your VTT file to your YouTube video.

Once we have this file created, we can then embed it into an HTML5 video element.

<!DOCTYPE HTML> <html>   <body>     <video controls autoplay>       <source src="your_video.mp4" type="video/mp4"/>       <track default kind="captions" srclang="en" label="English" src="your_caption_file.vtt"/>     </video>   </body> </html>

The <track> tag is sort of like a script that “plays” along with the video. We can use multiple tracks in the same video element. The default attribute indicates that a the track will be enabled automatically.

Let’s run down all the <track> attributes while we’re at it:

  • srclang indicates what language the track is in.
  • kind represents the type of track it is and there are five kinds:
    • subtitles are usually translations and descriptions of different parts of a video.
    • descriptions help unsighted users understand what is happening in a video.
    • captions provide un-hearing users an alternative to audio.
    • metadata is a track that is used by scripts and cannot be seen by users.
    • chapters assist in navigating video content.
  • label is a title for the text track that appears in the caption track
  • src is the source file for the track. It cannot come from a cross-origin source unless crossorigin is specified.

While WebVTT is designed specifically for video, you can still use it with audio by placing an audio file within a <video> element.

Digging into the structure of a WebVTT file

MDN has great documentation and outlines the body structure of a WebVTT file, which consists of up to six components. Here’s how MDN breaks it down:

  • An optional byte order mark (BOM)
  • The string “WEBVTT
  • An optional text header to the right of WEBVTT.
    • There must be at least one space after WEBVTT.
    • You could use this to add a description to the file.
    • You may use anything in the text header except newlines or the string “-->“.
  • A blank line, which is equivalent to two consecutive newlines.
  • Zero or more cues or comments.
  • Zero or more blank lines.

Note: a BOM is a unicode character that indicates the unicode encoding of the text file.

Bold, italic, and underline — oh my!

We can absolutely use some inline HTML formatting in WebVTT files! These are the ones that everyone is familiar with: <b>, <i>, and <u>. You use them exactly as you would in HTML.

WEBVTT  00:00:00.000 --> 00:00:03.000 align:start This is bold text  00:00:03.000 --> 00:00:06.000 align:middle This is italic text  00:00:06.000 --> 00:00:09.000 vertical:rl align:middle This is <u>underlined  text</u>

Cue settings

Cue settings are optional strings of text used to control the position of a caption. It’s sort of like positioning elements in CSS, like being able to place captions on the video.

For example, we could place captions to the right of a cue timing, control whether a caption is displayed horizontally or vertically, and define both the alignment and vertical position of the caption.

Here are the settings that are available to us.

Setting 1: Line

line controls the positioning of the caption on the y-axis. If vertical is specified (which we’ll look at next), then line will instead indicate where the caption will be displayed on the x-axis.

When specifying the line value, integers and percentages are perfectly acceptable units. In the case of using an integer, the distance per line will be equal to the height (from a horizontal perspective) of the first line. So, for example, let’s say the height of the first line of the caption is equal to 50px, the line value specified is 2, and the caption’s direction is horizontal. That means the caption will be positioned 100px (50px times 2) down from the top, up to a maximum equal to coordinates of the boundaries of the video. If we use a negative integer, it will move upward from the bottom as the value decreases (or, in the case of vertical:lr being specified, we will move from right-to-left and vice-versa). Be careful here, as it’s possible to position the captions off-screen in addition to the positioning being inconsistent across browsers. With great power comes great responsibility!

In the case of a percentage, the value must be between 0-100%, inclusive (sorry, no 200% mega values here). Higher values will move the caption from top-to-bottom, unless vertical:lr or vertical:rl is specified, in which case the caption will move along the x-axis accordingly.

As the value increases, the caption will appear further down the video boundaries. As the value decreases (including into the negatives), the caption will appear further up.

Tough picture this without examples, right? Here’s how this translates into code:

00:00:00.000 --> 00:00:03.000 line:50% This caption should be positioned horizontally in the approximate center of the screen.
00:00:03.000 --> 00:00:06.000 vertical:lr line:50% This caption should be positioned vertically in the approximate center of the screen.
00:00:06.000 --> 00:00:09.000 vertical:rl line:-1 This caption should be positioned vertically along the left side of the video.
00:00:09.000 --> 00:00:12.000 line:0 The caption should be positioned horizontally at the top of the screen.

Setting 2: Vertical

vertical indicates the caption will be displayed vertically and move in the direction specified by the line setting. Some languages are not displayed left-to-right and instead need a top-to-bottom display.

  00:00:00.000 --> 00:00:03.000 vertical:rl This caption should be vertical.
00:00:00.000 --> 00:00:03.000 vertical:lr This caption should be vertical.

Setting 3: Position

position specifies where the caption will be displayed along the x-axis. If vertical is specified, the position will instead specify where the caption will be displayed on the y-axis. It must be an integer value between 0% and 100%, inclusive.

00:00:00.000 --> 00:00:03.000 vertical:rl position:100% This caption will be vertical and toward the bottom.  00:00:03.000 --> 00:00:06.000 vertical:rl position:0% This caption will be vertical and toward the top.

At this point, you may notice that line and position are similar to the CSS flexbox properties for align-items and justify-content, and that vertical behaves a lot like flex-direction. A trick for remembering WebVTT directions is that line specifies a position perpendicular to the flow of the text, whereas position specifies the position parallel to the flow of the text. That’s why line suddenly moves along the horizontal axis, and position moves along the vertical axis if we specify vertical.

Setting 4: Size

size specifies the width of the caption. If vertical is specified, then it will set the height of the caption instead. Like other settings, it must be an integer between 0% and 100%, inclusive.

00:00:00.000 --> 00:00:03.000 vertical:rl size:50% This caption will fill half the screen vertically.
00:00:03.000 --> 00:00:06.000 position:0% This caption will fill the entire screen horizontally.

Setting 5: Align

align specifies where the text will appear horizontally. If vertical is specified, then it will control the vertical alignment instead.

The values we’ve got are: start, middle, end, left and right. Without vertical specified, the alignments are exactly what they sound like. If vertical is specified, they effectively become top, middle (vertically), and bottom. Using start and end as opposed to left and right, respectively, is a more flexible way of allowing the alignment to be based on the unicode-bidi CSS property’s plaintext value.

Note that align is not unaffected by vertical:lr or vertical:rl.

WEBVTT  00:00:00.000 --> 00:00:03.000 align:start This caption will be on the left side of the screen.  00:00:03.000 --> 00:00:06.000 align:middle This caption will be horizontally in the middle of the screen.  00:00:06.000 --> 00:00:09.000 vertical:rl align:middle This caption will be vertically in the middle of the screen.  00:00:09.000 --> 00:00:12.000 vertical:rl align:end This caption will be vertically at the bottom right of the screen regardless of vertical:lr or vertical:rl orientation.  00:00:12.000 --> 00:00:15.000 vertical:lr align:end This caption will be vertically at the bottom of the screen, regardless of the vertical:lr or vertical:rl orientation.  00:00:12.000 --> 00:00:15.000 align:left This caption will appear on the left side of the screen.  00:00:12.000 --> 00:00:15.000 align:right This caption will appear on the right side of the screen.

WebVTT Comments

WebVTT comments are strings of text that are only visible when reading the source text of the file, the same way we think of comments in HTML, CSS, JavaScript and any other language. Comments may contain a new line, but not a blank line (which is essentially two new lines).

WEBVTT  00:00:00.000 --> 00:00:03.000 - [Birds chirping] - It's a beautiful day!  NOTE This is a comment. It will not be visible to anyone viewing the caption.  00:00:04.000 --> 00:00:07.000 - [Creek trickling] - It is indeed!  00:00:08.000 --> 00:00:10.000 - Hello there!

When the caption file is parsed and rendered, the highlighted line above will be completely hidden from users. Comments can be multi-line as well.

There are three very important characters/strings to take note of that may not be used in comments: <, &, and -->. As an alternative, you can use escaped characters instead.

Not Allowed Alternative
NOTE PB&J NOTE PB&amp;J
NOTE 5 < 7 NOTE 5 &lt; 7
NOTE puppy --> dog NOTE puppy --&gt; do

A few other interesting WebVTT features

We’re going to take a quick look at some really neat ways we can customize and control captions, but that are lacking consistent browser support, at least at the time of this writing.

Yes, we can style captions!

WebVTT captions can, in fact, be styled. For example, to style the background of a caption to be red, set the background property on the ::cue pseudo-element:

video::cue {   background: red; }

Remember how we can use some inline HTML formatting in the WebVTT file? Well, we can select those as well. For example, to select and italic (<i>) element:

video::cue(i) {   color: yellow; }

Turns out WebVTT files support a style block, a lot like the way HTML files do:

WEBVTT  STYLE ::cue {   color: blue;   font-family: "Source Sans Pro", sans-serif; }

Elements can also be accessed via their cue identifiers. Note that cue identifiers use the same escaping mechanism as HTML.

WEBVTT  STYLE ::cue(#middle cue identifier) {   text-decoration: underline; } ::cue(#cue identifier ) {   font-weight: bold;   color: red; }  first cue identifier 00:00:00.000 --> 00:00:02.000 Hello, world!  middle cue identifier 00:00:02.000 --> 00:00:04.000 This cue identifier will have an underline!  cue identifier 3 00:00:04.000 --> 00:00:06.000 This one won't be affected, just like the first one!

Different types of tags

Many tags can be used to format captions. There is a caveat. These tags cannot be used in a <track> element where kind attribute is chapters. Here are some formatting tags you can use.

The class tag

We can define classes in the WebVTT markup using a class tag that can be selected with CSS. Let’s say we have a class, .yellowish that makes text yellow. We can use the tag <c.yellowish> in a caption. We can control lots of styling this way, like the font, the font color, and background color.

/* Our CSS file */ .yellowish {   color: yellow; } .redcolor {   color: red; }
WEBVTT  00:00:00.000 --> 00:00:03.000 <c.yellowish>This text should be yellow.</c> This text will be the default color.  00:00:03.000 --> 00:00:06.000 <c.redcolor>This text should be red.</c> This text will be the default color.

The timestamp tag

If you want to make captions appear at specific times, then you will want to use timestamp tags. They’re like fine-tuning captions to exact moments in time. The tag’s time must be within the given time range of the caption, and each timestamp tag must be later than the previous.

WEBVTT  00:00:00.000 --> 00:00:07.000 This <00:00:01.000>text <00:00:02.000>will <00:00:03.000>appear <00:00:04.000>over <00:00:05.000>6 <00:00:06.000>seconds.

The voice tag

Voice tags are neat in that they help identify who is speaking.

WEBVTT  00:00:00.000 --> 00:00:03.000 <v Alice>How was your day, Bob?  00:00:03.000 --> 00:00:06.000 <v Bob>Great, yours?

The ruby tag

The ruby tag is a way to display small, annotative characters above the caption.

WEBVTT  00:00:00.000 --> 00:00:05.000 <ruby>This caption will have text above it<rt>This text will appear above the caption.

Conclusion

And that about wraps it up for WebVTT! It’s an extremely useful technology and presents an opportunity to improve your site’s accessibility a great deal, particularly if you are working with video. Try some of your own captions out yourself to get a better feel for it!

CSS-Tricks

, , ,
[Top]

Grid, content re-ordering and accessibility

Take this:

<ol>   <li>Get hungry</li>   <li>Order pizza</li>   <li>Eat pizza</li> </ol>

That HTML ends up in the DOM that way (and thus how it is is exposed to assistive technology), and by default, those list items are also visually shown in that order. In most layout situations, the visual order will match that DOM order. Do nothing, and the list items will flow in the block direction of the document. Apply flexbox, and it will flow in the inline direction of the document.

But flexbox and grid also allow you to muck it up. Now take this:

ol {    display: flex;   flex-direction: row-reverse; }

In this case, the DOM order still makes sense, but the visual order is all wrong. It’s not just row-reverse. There are a number of flexbox and grid properties that can get involved and confuse things: the order property, flowing items into columns instead of rows, and positioning items specifically in unusual orders, among others. Even absolute positioning could cause the same trouble.

Manuel Matuzovic says:

If the visual order and the DOM order don’t match, it can irritate and confuse users up to a point where the experience is so bad that the site is unusable.

Rachel Andrew highlights this issue (including things we’ve published) as a big issue, and hopes we can get tools at the CSS level to help.

I think this is something we sorely need to address at a CSS level. We need to provide a way to allow the tab and reading order to follow the visual order. Source order is a good default, if you are taking advantage of normal flow, a lot of the time following the source is exactly what you want. However not always, not at every breakpoint. If we don’t give people a solution for this, we will end up with a mess. We’ve given people these great tools, and now I feel as if I’m having to tell people not to use them.

Direct Link to ArticlePermalink

The post Grid, content re-ordering and accessibility appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]