Tag: Some

Why Do Some HTML Elements Become Deprecated?

The internet has been around for a long while, and over time we’ve changed the way we think about web design. Many old techniques and ways of doing things have gotten phased out as newer and better alternatives have been created, and we say that they have been deprecated.

Deprecated. It’s a word we use and see often. But have you stopped to think about what it means in practice? What are some examples of deprecated web elements, and why don’t we use them any more?

What is deprecation?

In everyday English, to “deprecate” something is to express disapproval of it. For example, you might be inclined to deprecate a news story you don’t like.

When we’re speaking in a technical sense, however, deprecation is the discouragement of use for an old feature. Often, the old feature remains functional in the interests of backward compatibility (so legacy projects don’t break). In essence, this means that you can technically still do things the legacy way. It’ll probably still work, but maybe it’s better to use the new way. 

Another common scenario is when technical elements get deprecated as a prelude to their future removal (which we sometimes call “sunsetting” a feature). This provides everybody time to transition from the old way of working to the new system before the transition happens. If you follow WordPress at all, they recently did this with their radically new Gutenberg editor. They shipped it, but kept an option available to revert to the “classic” editor so users could take time to transition. Someday, the “classic” editor will likely be removed, leaving Gutenberg as the only option for editing posts. In other words, WordPress is sunsetting the “classic” editor.

That’s merely one example. We can also look at HTML features that were once essential staples but became deprecated at some point in time.

Why do HTML elements get deprecated?

Over the years, our way of thinking about HTML has evolved. Originally, it was an all-purpose markup language for displaying and styling content online.

Over time, as external stylesheets became more of a thing, it began to make more sense to think about web development differently — as a separation of concerns where HTML defines the content of a page, and CSS handles the presentation of it.

This separation of style and content brings numerous benefits:

  • Avoiding duplication: Repeating code for every instance of red-colored text on a page is unwieldy and inefficient when you can have a single CSS class to handle all of it at once. 
  • Ease of management: With all of the presentation controlled from a central stylesheet, you can make site-wide changes with little effort.
  • Readability: When viewing a website’s source, it’s a lot easier to understand the code that has been neatly abstracted into separate files for content and style. 
  • Caching: The vast majority of websites have consistent styling across all pages, so why make the browser download those style definitions again and again? Putting the presentation code in a dedicated stylesheet allows for caching and reuse to save bandwidth. 
  • Developer specialization: Big website projects may have multiple designers and developers working on them, each with their individual areas of expertise. Allowing a CSS specialist to work on their part of the project in their own separate files can be a lot easier for everybody involved. 
  • User options: Separating styling from content can allow the developer to easily offer display options to the end user (the increasingly popular ‘night mode’ is a good example of this) or different display modes for accessibility. 
  • Responsiveness and device independence: separating the code for content and visual presentation makes it much easier to build websites that display in very different ways on different screen resolutions.

However, in the early days of HTML there was a fair amount of markup designed to control the look of the page right alongside the content. You might see code like this: 

<center><font face="verdana" color="#2400D3">Hello world!</font></center>

…all of which is now deprecated due to the aforementioned separation of concerns. 

Which HTML elements are now deprecated?

As of the release of HTML5, use of the following elements is discouraged:

  • <acronym> (use <abbr> instead)
  • <applet> (use <object>)
  • <basefont> (use CSS font properties, like font-size, font-family, etc.)
  • <big> (use CSS font-size)
  • <center> (use CSS text-align)
  • <dir> (use <ul>)
  • <font> (use CSS font properties)
  • <frame> (use <iframe>)
  • <frameset> (not needed any more)
  • <isindex> (not needed any more)
  • <noframes> (not needed any more)
  • <s> (use text-decoration: line-through in CSS)
  • <strike> (use text-decoration: line-through in CSS)
  • <tt> (use <code>)

There is also a long list of deprecated attributes, including many elements that continue to be otherwise valid (such as the align attribute used by many elements). The W3C has the full list of deprecated attributes.

Why don’t we use table for layouts any more?

Before CSS became widespread, it was common to see website layouts constructed with the <table> element. While the <table> element is not deprecated, using them for layout is strongly discouraged. In fact, pretty much all HTML table attributes that were used for layouts have been deprecated, such as cellpadding, bgcolor and width

At one time, tables seemed to be a pretty good way to lay out a web page. We could make rows and columns any size we wanted, meaning we could put everything inside. Headers, navigation, footers… you name it!

That would create a lot of website code that looked like this:

<table border="0" cellpadding="0" cellspacing="0" width="720">   <tr>     <td colspan="10"><img name="logobar" src="logobar.jpg" width="720" height="69" border="0" alt="Logo"></td>   </tr>   <tr>     <td rowspan="2" colspan="5"><img name="something" src="something.jpg" width="495" height="19" border="0" alt="A picture of something"></td>     <td>Blah blah blah!</td>     <td colspan="3">    <tr>   <!--  and so on --> </table>

There are numerous problems with this approach:

  • Complicated layouts often end up with tables nested inside other tables, which creates a headache-inducing mess of code. Just look at the source of any email newsletter.
  • Accessibility is problematic, as screen readers tend to get befuddled by the overuse of tables.
  • Tables are slow to render, as the browser waits for the entire table to download before showing it on the screen.
  • Responsible and mobile-friendly layouts are very difficult to create with a table-based layout. We still have not found a silver bullet for responsive tables (though many clever ideas exist).

Continuing the theme of separating content and presentation, CSS is a much more efficient way to create the visual layout without cluttering the code of the main HTML document. 

So, when should we use<table>? Actual tabular data, of course! If you need to display a list of baseball scores, statistics or anything else in that vein, <table> is your friend. 

Why do we still use <b> and <i> tags?

“Hang on just a moment,” you might say. “How come bold and italic HTML tags are still considered OK? Aren’t those forms of visual styling that ought to be handled with CSS?”

It’s a good question, and one that seems difficult to answer when we consider that other tags like <center> and <s> are deprecated. What’s going on here?

The short and simple answer is that <b> and <i> would probably have been deprecated if they weren’t so widespread and useful. CSS alternatives seem somewhat unwieldy by comparison:

<style>   .emphasis { font-weight:bold } </style>      This is a <span class="emphasis">bold</span> word!  This is a <span style="font-weight:bold">bold</span> word!  This is a <b>bold</b> word!

The long answer is that these tags have now been assigned some semantic meaning, giving them value beyond pure visual presentation and allowing designers to use them to confer additional information about the text they contain.

This is important because it helps screen readers and search crawlers better understand the purpose of the content wrapped in these tags. We might italicize a word for several reasons, like adding emphasis, invoking the title of a creative work, referring to a scientific name, and so on. How does a screen reader know whether to place spoken emphasis on the word or not?

<b> and <i>have companions, including <strong>, <em> and <cite>. Together, these tags make the meaning context of text clearer:

  • <b> is for drawing attention to text without giving it any additional importance. It’s used when we want to draw attention to something without changing the inflection of the text when it is read by a screen reader or without adding any additional weight or meaning to the content for search engines.
  • <strong> is a lot like <b> but signals the importance of something. It’s the same as changing the inflection of your voice when adding emphasis on a certain word.
  • <i> italicizes text without given it any additional meaning or emphasis. It’s perfect for writing out something that is normally italicized, like the scientific name of an animal.
  • <em> is like <i> in that it italicizes text, but it provides adds additional emphasis (hence the tag name) without adding more importance in context. (‘I’m sure I didn’t forget to feed the cat’). 
  • <cite> is what we use to refer to the title of a creative work, say a movie like The Silence of the Lambs. This way, text is styled but doesn’t affect the way the sentence would be read aloud. 

In general, the rule is that <b> and <i> are to be used only as a last resort if you can’t find anything more appropriate for your needs. This semantic meaning allows <b> and <i> to continue to have a place in our modern array of HTML elements and survive the deprecation that has befallen other, similar style tags.

On a related note, <u> — the underline tag — was at one time deprecated, but has since been restored in HTML5 because it has some semantic uses (such as annotating spelling errors).

There are many other HTML elements that might lend styling to content, but primarily serve to provide semantic meaning to content. Mandy Michael has an excellent write-up that covers those and how they can be used (and even combined!) to make the most semantic markup possible.

Undead HTML attributes

Some deprecated elements are still in widespread use around the web today. After all, they still work — they’re just discouraged.

This is sometimes because word hasn’t gotten around that that thing you’ve been using for ages isn’t actually the way it’s done any more. Other times, it’s due to folks who don’t see a compelling reason to change from doing something that works perfectly well. Hey, CSS-Tricks still uses the teletype element for certain reasons.

One such undead HTML relic is the align attribute in otherwise valid tags, especially images. You may see <img> tags with a border attribute, although that attribute has long been deprecated. CSS, of course, is the preferred and modern method for that kind of styling presentation.


Staying up to date with deprecation is key for any web developer. Making sure your code follows the current recommendations while avoiding legacy elements is an essential best practice. It not only ensures that your site will continue to work in the long run, but that it will play nicely with the web of the future.

Questions? Post a comment! You can also find me over at Angle Studios where I work.

The post Why Do Some HTML Elements Become Deprecated? appeared first on CSS-Tricks.

CSS-Tricks

, , , ,

Just Dropping Some Type Links

I’ve had a bunch of tabs open that just so happen to all be related to typography, so I figured I’d give myself the mental release of closing them by blogging them. How’s that for a blog post format for ya: whatever random tabs you’ve had open for far too long.

  • Times New Roman is popular on the web in the sense that it’s a default font installed on most computers and safe to use without having to load any web fonts. But it’s also the default font that (all?) web browsers use if you don’t declare a font-family at all so, in that sense, it sometimes feels like a site is broken on accident when Times is used. Typewolf has a nice list of alternatives if you like the vibe but need something different.
  • Speaking of Times, err, The New York Times profiles TypeThursday with a pretty funny correction where they got the typeface name wrong.
  • In the last month of 2019, Tyopgraphica published their favorite typefaces of 2018. Fern grabs me.
  • Una Kravets has a “designing in the browser” video about typography on the Chrome Developers channel on YouTube. About 11 minutes in, she gets into variable fonts which are just incredible. I know they are capable of all sorts of amazing things (even animation), but I remain the most excited about performance: loading one font and having tons of design control.
  • Florens Verschelde’s “A short history of body copy sizes on the Web” gets into how typical font size usage has crept up and up over the years.
  • Alina Sava makes the argument that font licensing is ill. Primarily: pricing web fonts based on page views. As someone who works on some high-traffic / fairly-low-profit websites, it’s hard to disagree.
  • Matej Latin covers five fonts designed for coding that have ligatures. Ya know, instead of != you get , but only visually rather than actually changing the characters that are used as I did there. Ligatures are a neat trick to use (another trick: ligatures as icons), but Matthew Butterick says “hell no”: The ligature introduces an ambiguity that wasn’t there before. I find it notable that Operator Mono chose not to go there. I feel like I overheard a discussion about it once but can’t dig it up now. I know there is a way to add them, and it’s a little surprising to me that’s legal.
  • Trent popped some new fonts on his blog and shared his font shopping list.
  • You might have noticed some new fonts around here on CSS-Tricks as well, as of a few weeks ago. I just wanted to freshen up the place as I was getting sick of looking at system fonts (they started looking bad to me on Catalina, which is something Andy Baio pointed out is a Chrome Bug, but still). The CSS-Tricks logo has long been Gotham Rounded, so I went back to Hoefler&Co. for the font choices here to kinda stay in the family. The headers use Ringside, monospace content uses Operator Mono, and the body uses Sentinel.

The post Just Dropping Some Type Links appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Some CSS Grid Strategies for Matching Design Mockups

The world of web development has always had a gap between the design-to-development handoff. Ambitious designers want the final result of their effort to look unique and beautiful (and true to their initial vision), whereas many developers find more value in an outcome that is consistent, dependable, and rock solid (and easy to code). This dynamic can result in sustained tension between the two sides with both parties looking to steer things their own way.

While this situation is unavoidable to some extent, new front-end technology can play a role in bringing the two sides closer together. One such technology is CSS grid. This post explores how it can be used to write CSS styles that match design layouts to a high degree of fidelity (without the headache!).

A common way that designers give instructions to front-end developers is with design mockups (by mockups, we’re talking about deliverables that are built in Sketch, XD, Illustrator, Photoshop etc). All designers work differently to some degree (as do developers), but many like to base the structure of their layouts on some kind of grid system. A consistent grid system is invaluable for communicating how a webpage should be coded and how it should respond when the size of the user’s screen differs from the mockup. As a developer, I really appreciate designers who take the trouble to adopt a well thought-out grid system.

A 12-column layout is particularly popular, but other patterns are common as well. Software like Sketch and XD makes creating pages that follow a preset column layout pretty easy — you can toggle an overlay on and off with the click of a button.

A grid layout designed in Sketch (left) and Adobe XD (right)

Once a grid system is implemented, most design elements should be positioned squarely within it. This approach ensures that shapes line up evenly and makes for a more appealing appearance. In addition to being visually attractive, a predictable grid gives developers a distinct target to shoot for when writing styles.

Unfortunately, this basic pattern can be deceptively difficult to code accurately. Frameworks like Bootstrap are often used to create grid layouts, but they come with downsides like added page weight and a lack of fine-grained control. CSS grid offers a better solution for the front-end perfectionist. Let’s look at an example.

A 14-column grid layout

The design above is a good application for grid. There is a 14-column pattern with multiple elements positioned within it. While the boxes all have different widths and offsets, they all adhere to the same grid. This layout can be made with flexbox — and even floats — but that would likely involve some very specific math to get a pixel-perfect result across all breakpoints. And let’s face it: many front-end developers don’t have the patience for that. Let’s look at three CSS grid layout strategies for doing this kind of work more easily.

Strategy 1: A basic grid

See the Pen
Basic Grid Placement
by chris geel (@RadDog25)
on CodePen.

The most intuitive way to write an evenly spaced 12-column layout would probably be some variation of this. Here, an outer container is used to control the outside gutter spacing with left and right padding, and an inner row element is used to restrain content to a maximum width. The row receives some grid-specific styling:

display: grid; grid-template-columns: repeat(12, 1fr); grid-gap: 20px;

This rule defines the grid to consist of 12 columns, each having a width of one fractional unit (fr). A gap of 20px between columns is also specified. With the column template set, the start and end of any child column can be set quite easily using the grid-column property. For example, setting grid-column: 3/8 positions that element to begin at column three and span five columns across to column eight.

We can already see a lot of value in what CSS grid provides in this one example, but this approach has some limitations. One problem is Internet Explorer, which doesn’t have support for the grid-gap property. Another problem is that this 12-column approach does not provide the ability to start columns at the end of gaps or end columns at the start of gaps. For that, another system is needed.

Strategy 2: A more flexible grid

See the Pen
More Flexible Grid Placement
by chris geel (@RadDog25)
on CodePen.

Although grid-gap may be a no go for IE, the appearance of gaps can be recreated by including the spaces as part of the grid template itself. The repeat function available to grid-template-columns accepts not just a single column width as an argument, but repeating patterns of arbitrary length. To this end, a pattern of column-then-gap can be repeated 11 times, and then the final column can be inserted to complete the 12-column / 11 interior gap layout desired:

grid-template-columns: repeat(11, 1fr 20px) 1fr;

This gets around the IE issue and also allows for columns to be started and ended on both columns or gaps. While being a nice improvement over the previous method, it still has some room to grow. For example, what if a column was to be positioned with one side spanning to the outer edge of the screen, and the other fit within the grid system? Here’s an example:

A grid Layout with an that’s item flush to the outer edge

In this layout, the card (our left column) begins and ends within the grid. The main image (our right column) begins within the grid as well, but extends beyond the grid to the edge of the screen. Writing CSS for this can be a challenge. One approach might be to position the image absolutely and pin it to the right edge, but this comes with the downside of taking it out of the document flow (which might be a problem if the image is taller than the card). Another idea would be to use floats or flexbox to maintain document flow, but this would entail some tricky one-off calculation to get the widths and spacing just right. Let’s look at a better way.

Strategy 3: An even more flexible grid

See the Pen
Right Edge Aligned image with grid
by chris geel (@RadDog25)
on CodePen.

This technique builds on the idea introduced in the last revision. Now, instead of having the grid exist within other elements that define the gutter sizes and row widths, we’re integrating those spaces with the grid’s pattern. Since the gutters, columns, and gaps are all incorporated into the template, child elements can be positioned easily and precisely on the grid by using the grid-column property.

$ row-width: 1140px; $ gutter: 30px; $ gap: 20px; $ break: $ row-width + 2 * $ gutter; $ col-width-post-break: ($ row-width - 11 * $ gap) / 12;    .container {   display: grid;   grid-template-columns: $ gutter repeat(11, calc((100% - 2 * #{$ gutter} - 11 * #{$ gap})/12) #{$ gap}) calc((100% - 2 * #{$ gutter} - 11 * #{$ gap})/12) $ gutter;   @media screen and (min-width: #{$ break}) {     grid-template-columns: calc(0.5 * (100% - #{$ row-width})) repeat(11, #{$ col-width- post-break} #{$ gap}) #{$ col-width-post-break} calc(0.5 * (100% - #{$ row-width}));   } }

Yes, some math is required to get this just right. It’s important to have the template set differently before and after the maximum width of the row has been realized. I elected to use SCSS for this because defining variables can make the calculation a lot more manageable (not to mention more readable for other developers). What started as a 12-part pattern grew to a 23-part pattern with the integration of the 11 interior gaps, and is now 25 pieces accounting for the left and right gutters.

One cool thing about this approach is that it can be used as the basis for any layout that adheres to the grid once the pattern is set, including traditionally awkward layouts that involve columns spanning to outside edges. Moreover, it serves as a straightforward way to precisely implement designs that are likely to be handed down in quality mockups. That is something that should make both developers and designers happy!

There are a couple of caveats…

While these techniques can be used to crack traditionally awkward styling problems, they are not silver bullets. Instead, they should be thought of as alternative tools to be used for the right application.

One situation in which the second and third layout patterns are not appropriate are layouts that require auto placement. Another would be production environments that need to support browsers that don’t play nice with CSS grid.

The post Some CSS Grid Strategies for Matching Design Mockups appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

Some Things You Oughta Know When Working with Viewport Units

David Chanin has a quickie article summarizing a problem with setting an element’s height to 100vh in mobile browsers and then also positioning something on the bottom of that.

Summarized in this graphic:

The trouble is that Chrome isn’t taking the address bar (browser chrome) into account when it’s revealed which cuts off the element short, forcing the bottom of the element past the bottom of the actual viewport.

<div class="full-page-element">   <button>Button</button> </div>
.full-page-element {   height: 100vh;   position: relative; }  .full-page-element button {   position: absolute;   bottom: 10px;   left: 10px; }

You’d expect that button in the graphic to be visible (assuming this element is at the top of the page and you haven’t scrolled) since it’s along the bottom edge of a 100vh element. But it’s actually hidden behind the browser chrome in mobile browsers, including iOS Safari or Android Chrome.

I use this a lot:

body {   height: 100vh; /* Nice to not have to think about the HTML element parent   margin: 0; }

It’s just a quick way to make sure the body is full height without involving any other elements. I’m usually doing that on pretty low-stakes demo type stuff, but I’m told even that is a little problematic because you might experience jumpiness as browser chrome appears and disappears, or things may not be quite as centered as you’d expect.

You’d think you could do body { height: 100% }, but there’s a gotcha there as well. The body is a child of <html> which is only as tall as the content it contains, just like any other element.

If you need the body to be full height, you have to deal with the HTML element as well:

html, body {    height: 100%; }

…which isn’t that big of a deal and has reliable cross-browser consistency.

It’s the positioning things along the bottom edge that is tricky. It is problematic because of position: absolute; within the “full height” (often taller-than-visible) container.

If you are trying to place something like a fixed navigation bar at the bottom of the screen, you’d probably do that with position: fixed; bottom: 0; and that seems to work fine. The browser chrome pushes it up and down as you’d expect (video).

Horizontal viewport units are just as weird and problematic due to another bit of browser UI: scrollbars. If a browser window has a visible scrollbar, that scrollbar will usually eat into the visual space although a value of 100vw is calculated as if the scrollbar wasn’t there. In other words, 100vw will cause horizontal scrolling in a way you probably wouldn’t expect.

See the Pen
CSS Vars for viewport width minus scrollbar
by Shaw (@shshaw)
on CodePen.

Our last CSS wishlist roundup mentioned better viewport unit handling a number of times, so developers are clearly pretty interested in having better solutions for these things. I’m not sure what that would mean for web compatibility though, because changing the way they work might break all the workarounds we’ve used that are surely still out in the wild.

The post Some Things You Oughta Know When Working with Viewport Units appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]

Some Hands-On with the HTML Dialog Element

This is me looking at the HTML <dialog> element for the first time. I’ve been aware of it for a while, but haven’t taken it for a spin yet. It has some pretty cool and compelling features. I can’t decide for you if you should use it in production on your sites, but I’d think it’s starting to be possible.

It’s not just a semantic element, it has APIs and special CSS.

We’ll get to that stuff in a moment, but it’s notable because it makes the browser support stuff significant.

When we first got HTML5 elements like <article>, it pretty much didn’t matter if the browser supported it or not because nothing was worse-off in those scenarios if you used it. You could make it block-level and it was just like a meaningless div you would have used anyway.

That said, I wouldn’t just use <dialog> as a “more semantic <div> replacement.” It’s got too much functionality for that.

Let’s do the browser support thing.

As I write:

  • Chrome’s got it (37+), so Edge is about to get it.
  • Firefox has the User-Agent (UA) styles in place (69+), but the functionality is behind a dom.dialog_element.enabled flag. Even with the flag, it doesn’t look like we get the CSS stuff yet.
  • No support from Safari.

It’s polyfillable.

It’s certainly more compelling to use features with a better support than this, but I’d say it’s close and it might just cross the line if you’re the polyfilling type anyway.

On to the juicy stuff.

A dialog is either open or not.

<dialog>   I'm closed. </dialog>  <dialog open>   I'm open. </dialog>

There is some UA styling to them.

It seems to match in Chrome and Firefox. The UA stylesheet has it centered with auto margins, thick black lines, sized to content.

See the Pen
Basic Open Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

Like any UA styles, you’ll almost surely override them with your own fancy dialog styles — shadows and typography and whatever else matches your site’s style.

There is a JavaScript API for opening and closing them.

Say you have a reference to the element named dialog:

dialog.show(); dialog.hide();

See the Pen
Basic Togglable Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

You should probably use this more explicit command though:

dialog.showModal();

That’s what makes the backdrop work (and we’ll get to that soon). I’m not sure I quite grok it, but the the spec talks about a “pending dialog stack” and this API will open the modal pending that stack. Here’s a modal that can open a second stacking modal:

See the Pen
Basic Open Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

There’s also an HTML-based way close them.

If you put a special kind of form in there, submitting the form will close the modal.

<form method="dialog">   <button>Close</button> </form>

See the Pen
Dialog with Form that Closes Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

Notice that if you programmatically open the dialog, you get a backdrop cover.

This has always been one of the more finicky things about building your own dialogs. A common UI pattern is to darken the background behind the dialog to focus attention on the dialog.

We get that for free with <dialog>, assuming you open it via JavaScript. You control the look of it with the ::backdrop pseudo-element. Instead of the low-opacity black default, let’s do red with stripes:

See the Pen
Custom Dialog Backdrop
by Chris Coyier (@chriscoyier)
on CodePen.

Cool bonus: you can use backdrop-filter to do stuff like blur the background.

See the Pen
Native Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

It moves focus for you

I don’t know much about this stuff, but I can fire up VoiceOver on my Mac and see the dialog come into focus see that when I trigger the button that opens the modal.

It doesn’t trap focus there, and I hear that’s ideal for modals. We have a clever idea for that utilizing CSS you could explore.

Rob Dodson said: “modals are actually the boss battle at the end of web accessibility.” Kinda nice that the native browser version helps with a lot of that. You even automatically get the Escape key closing functionality, which is great. There’s no click outside to close, though. Perhaps someday pending user feedback.

Ire’s article is a go-to resource for building your own dialogs and a ton of accessibility considerations when using them.

The post Some Hands-On with the HTML Dialog Element appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Some Notes About Accessibility

Earlier this month Eric Bailey wrote about the current state of accessibility on the web and why it felt like fighting an uphill battle:

As someone with a good deal of interest in the digital accessibility space, I follow WebAIM’s work closely. Their survey results are priceless insights into how disabled people actually use the web, so when the organization speaks with authority on a subject, I listen.

WebAIM’s accessibility analysis of the top 1,000,000 homepages was released to the public on February 27, 2019. I’ve had a few days to process it, and frankly, it’s left me feeling pretty depressed. In a sea of already demoralizing findings, probably the most notable one is that pages containing ARIA—a specialized language intended to aid accessibility—are actually more likely to have accessibility issues.

Following up from that post, Ethan Marcotte jotted down his thoughts on the matter and about who has the responsibility to fix these issues in the long run:

Organizations like WebAIM have, alongside countless other non-profits and accessibility advocates, been showing us how we could make the web live up to its promise as a truly universal medium, one that could be accessed by anyone, anywhere, regardless of ability or need. And we failed.

I say we quite deliberately. This is on us: on you, and on me. And, look, I realize it may sting to read that. Hell, my work is constantly done under deadline, the way I work seems to change every year month, and it can feel hard to find the time to learn more about accessibility. And maybe you feel the same way. But the fact remains that we’ve created a web that’s actively excluding people, and at a vast, terrible scale. We need to meditate on that.

I suppose the lesson I’m taking from this is, well, we need to much, much more than meditating. I agree with Marcy Sutton: accessibility is a civil right, full stop. Improving the state of accessibility on the web is work we have to support. The alternative isn’t an option. Leaving the web in its current state isn’t fair. It isn’t just.

I entirely agree with Ethan here – we all have a responsibility to make the web a better place for everyone and especially when it comes to accessibility where the bar is so very low for us now. This isn’t to say that I know best, because there’s been plenty of times when I’ve dropped the ball when I’m designing something for the web.

What can we do to tackle the widespread issue surrounding web accessibility?

Well, as Eric mentions in his post, it’s first and foremost a problem of education and he points to Firefox and their great accessibility inspector as a tool to help us see and understand accessibility principles in action:

An image of the Firefox Accessibility tool inspecting the CSS-Tricks website

Marco Zehe is on the Firefox accessibility team wrote and about what the inspector is and how to use it:

This inspector is not meant as an evaluation tool. It is an inspection tool. So it will not give you hints about low contrast ratios, or other things that would tell you whether your site is WCAG compliant. It helps you inspect your code, helps you understand how your web site is translated into objects for assistive technologies.

Chris also wrote up some of his thoughts a short while ago, including other accessibility testing tools and checklists that can help us get started making more accessible experiences. The important thing to note here is that these tools need to be embedded within our process for web design if they’re going to solve these issues.

We can’t simply blame our tools.

I know the current state of web accessbility is pretty bad and that there’s an enormous amount of work to do for us all, but to be honest, I can’t help but feel a little optimistic. For the first time in my career, I’ve had designers and engineers alike approach me excitedly about accessibility. Each year, there are tons of workshops, articles, meetups, and talks (and I particularly like this talk by Laura Carvajal) on the matter meaning there’s a growing source of referential content that can teach us to be better.

And I can’t help but think that all of these conversations are a good sign – but now it’s up to us to do the work.

The post Some Notes About Accessibility appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]