I like the this wrap-up statement from Hidde de Vries:
In modern browsers, our markup becomes an accessibility tree that ultimately informs what our interface looks like to assistive technologies. It doesn’t matter as much whether you’ve written this markup:
- in a
.htmlfile- in Twig, Handlebars or Nunjucks
- as the
<template>in a Vue Single File Component- exported in the JSX of your React component
- outputted by a weird legacy CMS
It is which markup that determines if your site is pleasurable to experience for AT users. In short: it’s the markup that matters
As a front-end developer, you’ll find yourself writing markup in lots of different places with lots of different technologies. I think it behooves you think of how best to write it regardless of where and how.
@Chris Coyier
Does it mean we should now concentrate on how we organize our markup rather than learning how to integrate accessibility code in our markup.
Because , I just started learning how to make my site accessible for AT users.
@Obed absolutely yes. Not all visitors to your site who suffer from a disability will be using what is considered to be tradition assistive technology. For example, some sufferers of photosensitive epilepsy might disable CSS and/or Javascript in their browser to prevent unwanted animations (browser support for
prefers-reduced-motionis pretty low at the moment and can’t be relied upon by them), or may use the browsers “reading mode”. This means that the structure of your HTML is especially important.