Making Single Page Apps Accessible: It's easier than you think - Jess Budd - NDC Sydney 2024

00:52:20
https://www.youtube.com/watch?v=zfwa91Abkhw

概要

TLDRThe presentation at NDC Sydney, given by J Bud, a senior software engineer, focuses on enhancing the accessibility of single page applications. The speaker discusses the inherent challenges JavaScript frameworks pose to web accessibility but emphasizes that these can be overcome with proper practices. Highlighting the principles of the Web Content Accessibility Guidelines (WCAG), Bud explains the importance of using proper HTML elements to benefit not only people with disabilities but all users, including those in challenging environments. HTML’s built-in accessibility features should be leveraged, as they ensure semantic content comprehension by assistive technologies like screen readers. The talk also covers strategies for managing focus and updating page titles in single-page apps, offering practical coding solutions. Methods to test for accessibility issues using automated and manual techniques are shared, underscoring their value despite limitations. Key insights include the value of meaningful markup, careful handling of forms, and the significance of visible focus styles. Ultimately, Bud posits that these efforts help create a web that serves a diverse range of human needs and situations.

収穫

  • 🚀 Single page applications can be made accessible with the right techniques.
  • 📝 Web accessibility benefits everyone, not just those with disabilities.
  • 🌐 HTML's semantic elements are key to making accessible apps.
  • 🎯 Managing focus and page titles is crucial in single-page apps.
  • 🔧 Testing for accessibility requires both automated and manual methods.
  • 🔍 Use proper HTML labels and linking for form fields.
  • 🎨 Visible focus styles should not be removed, but customized.
  • 📊 Proper HTML structure aids SEO and accessibility simultaneously.
  • 🛠️ Framework knowledge helps apply accessibility techniques effectively.
  • 🤝 Accessible web design connects diverse users and fulfills various needs.

タイムライン

  • 00:00:00 - 00:05:00

    The speaker, J Bud, introduces their talk at NDC Sydney about making single page applications more accessible. They express gratitude to the audience for choosing this talk over others. As an experienced software engineer and a digital accessibility consultant, J Bud highlights the importance of accessibility, reflecting on Tim Berners-Lee's vision for a universal web. They stress that accessibility issues often arise not from technology itself but from developers lacking knowledge on making applications accessible.

  • 00:05:00 - 00:10:00

    Accessibility benefits not only those with disabilities but everyone, citing technologies like speech-to-text and automatic doors as examples originally designed for disability that are now widely used. The speaker explains the acronym 'A11Y' and discusses the significant portion of the population living with disabilities. They categorize disabilities into visual, auditory, motor, and cognitive, emphasizing the expected increase in these issues as people age.

  • 00:10:00 - 00:15:00

    The speaker introduces the Web Content Accessibility Guidelines (WCAG), breaking it down into four principles: perceivable, operable, understandable, and robust. These guidelines, updated to version 2.2, provide technical standards for accessibility. J Bud highlights three levels of adherence—A, AA, and AAA—encouraging developers to aim for a minimum of level AA to ensure they meet industry standards.

  • 00:15:00 - 00:20:00

    The talk transitions to HTML's role in accessibility, emphasizing that using semantic markup provides significant accessibility benefits. The speaker contrasts accessible HTML elements with 'div soup' and custom components that lack inherent accessibility features. They highlight the importance of meaningful markup for both screen readers and SEO.

  • 00:20:00 - 00:25:00

    J Bud emphasizes that each form input must have a linked label, explaining the importance of this connection for screen readers. They discuss using unique IDs, especially in single page applications with reusable components, and the problems with placeholders as a substitute for labels. They encourage developers to include helper text, making forms more accessible and improving usability.

  • 00:25:00 - 00:30:00

    Focusing on touch targets, the speaker explains how linking labels and inputs increase target areas, which benefits users with motor disabilities. They describe using HTML attributes like autocomplete to enhance input accessibility and discuss best practices for visible focus styles. The significance of focus indicators for keyboard and assistive technology users is highlighted, with a recommendation to style focus elements to improve usability.

  • 00:30:00 - 00:35:00

    Addressing the unique challenges of single page applications (SPAs), the speaker discusses the differences in routing between SPAs and traditional multi-page applications. They elaborate on how SPAs update parts of the page without a full refresh, which can confuse screen readers. Strategies for updating page titles and managing focus to improve accessibility in SPAs are presented, emphasizing thoughtful navigation management.

  • 00:35:00 - 00:40:00

    The speaker explains focus management, detailing its importance in SPAs and dynamic content updates. Options for managing focus include setting focus on page load or focusing new content directly. The speaker suggests best practices backed by research for intuitive user experience. Techniques to create accessible modals and the role of the HTML dialog element are also examined, enhancing ease of use.

  • 00:40:00 - 00:45:00

    The dynamic of testing accessibility is covered through both automated and manual methods. Automated tools inside code editors, such as AI-based suggestions and ESLint plugins, are recommended for early detection of accessibility issues. The speaker shares insights on leveraging tools like AXE core for deeper analysis and browser dev tools to inspect the accessibility tree, aiding in building accessible user interfaces.

  • 00:45:00 - 00:52:20

    In the conclusion, the speaker stresses the importance of manual testing, particularly using keyboards and screen readers to assess accessibility. They caution that automated tools only catch 20-30% of issues, highlighting the need for manual assessments. The talk concludes with a reminder that the web connects people, underpinning the vital role of developing accessible applications for diverse humans with different needs.

もっと見る

マインドマップ

ビデオQ&A

  • What is the talk at NDC Sydney about?

    The talk is about making single page applications more accessible.

  • Who is the speaker at this NDC Sydney session?

    The speaker is J Bud, a senior software engineer at a company called Hup.

  • Why does the speaker believe good HTML practices are important in JavaScript frameworks?

    Good HTML practices are crucial because they help maintain web accessibility and functionality, especially in a JavaScript-heavy environment.

  • What benefits does web accessibility provide?

    Web accessibility benefits everyone, including people with disabilities, temporary impairments, and in challenging environments.

  • How does the speaker suggest dealing with visible focus styles in web design?

    The speaker suggests replacing default focus styles with custom on-brand styles using the 'focus-visible' pseudo-class instead of removing them.

  • What is the significance of the Web Content Accessibility Guidelines (WCAG) discussed?

    WCAG provides technical standards to ensure web platforms are accessible. They are critical when developing applications, especially if compliance is required.

  • Why are autocomplete and tab index properties important for form inputs?

    Autocomplete and tab index properties enhance form accessibility by aiding input navigation and data entry for various users, including those with disabilities.

  • What challenges do single page applications pose for accessibility?

    Single page applications complicate accessibility because they do not naturally trigger full page refreshes, which can hinder page title updates and keyboard focus resetting.

ビデオをもっと見る

AIを活用したYouTubeの無料動画要約に即アクセス！
字幕
en
オートスクロール:
  • 00:00:06
    all right I think we'll get
  • 00:00:08
    started welcome thank you for having me
  • 00:00:11
    at NDC it's my second time at NDC Sydney
  • 00:00:14
    first time
  • 00:00:15
    speaking very excited to be here um to
  • 00:00:19
    talk about single page applications and
  • 00:00:21
    how we can make them more accessible and
  • 00:00:22
    thank you for coming along to my talk I
  • 00:00:24
    know that there were lots of other
  • 00:00:26
    really good talks on in this time slot
  • 00:00:28
    so appreciate that you are caring enough
  • 00:00:30
    about accessibility to come and learn a
  • 00:00:32
    bit more about it uh my name is j Bud uh
  • 00:00:36
    I'm a senior software engineer at a sty
  • 00:00:39
    company called hup who is an ndis
  • 00:00:41
    registered
  • 00:00:42
    provider since Twitter imploded uh I
  • 00:00:46
    joined all the things so you can find me
  • 00:00:48
    anywhere now um I'm basically just
  • 00:00:50
    hedging my bets to see where uh The Tech
  • 00:00:53
    Community kind of lands um but I put my
  • 00:00:56
    handles at the bottom of all the slides
  • 00:00:58
    so um if you'd like to reach out any
  • 00:01:02
    platform of your choice I'll be there
  • 00:01:03
    and I'd love to hear from
  • 00:01:05
    you uh previously I've worked for the uh
  • 00:01:09
    Center of inclusive design as a digital
  • 00:01:11
    accessibility consultant so I'm a bit of
  • 00:01:13
    an accessibility nerd uh and I'm a huge
  • 00:01:16
    lover of Lego uh just to give you a bit
  • 00:01:19
    of an idea of how much I love Lego this
  • 00:01:21
    is a photo of me uh holding the Lego
  • 00:01:24
    Masters trophy cup with the winners of
  • 00:01:27
    season five of the Australian Lego
  • 00:01:29
    master s does anyone watch Lego
  • 00:01:31
    Masters yeah a few people yes yes I was
  • 00:01:34
    so stoked um my husband says I didn't
  • 00:01:37
    look this ched on our wedding day so I
  • 00:01:40
    was really really
  • 00:01:42
    chaffed um so does anyone um recognize
  • 00:01:45
    this
  • 00:01:46
    guy it's uh Tim burners Lee the inventor
  • 00:01:50
    of the worldwide web uh the reason we
  • 00:01:52
    all have jobs today uh and he had a
  • 00:01:56
    vision of a universal web uh where
  • 00:02:00
    everyone has equal access regardless of
  • 00:02:02
    income regardless of location regardless
  • 00:02:05
    of ability or disability and it's a
  • 00:02:08
    great
  • 00:02:09
    vision but we're kind of messing it up
  • 00:02:13
    mostly with JavaScript HTML is generally
  • 00:02:16
    pretty accessible out of the box uh so
  • 00:02:19
    browsers and assisted Technologies
  • 00:02:20
    generally know what to do with it um but
  • 00:02:23
    since we've all started using JF
  • 00:02:24
    JavaScript Frameworks the web has become
  • 00:02:27
    a little less accessible but doesn't
  • 00:02:30
    have to be that way there's nothing
  • 00:02:32
    inherent in react or view that prevents
  • 00:02:35
    us from building accessible web apps
  • 00:02:38
    it's just that sometimes we as
  • 00:02:39
    developers don't know what we need to do
  • 00:02:42
    uh to make our apps more accessible So
  • 00:02:45
    today we're going to talk about how we
  • 00:02:46
    can still use all these cool Frameworks
  • 00:02:48
    while still fulfilling Tim's vision of
  • 00:02:50
    an accessible web for
  • 00:02:52
    everyone can I get a show of hands uh
  • 00:02:55
    how many people in the room are using
  • 00:02:57
    JavaScript Frameworks either day-to-day
  • 00:02:59
    or your side projects oh good yeah I'm
  • 00:03:02
    glad it's so pretty much everybody I was
  • 00:03:04
    bit worried that net crowd there
  • 00:03:06
    wouldn't be a lot of
  • 00:03:08
    people uh so the good news is there is
  • 00:03:10
    something inherent in single page apps
  • 00:03:12
    that is a plus for
  • 00:03:14
    accessibility uh so the modularity that
  • 00:03:16
    single page apps provide means we can
  • 00:03:18
    build an accessible component once and
  • 00:03:21
    then just reuse it over and over again
  • 00:03:23
    so this is especially true if you use a
  • 00:03:25
    design system in your organization and
  • 00:03:28
    everything just becomes a lot easier if
  • 00:03:30
    we can get our foundational uh
  • 00:03:32
    components
  • 00:03:34
    compliant so there are a lot of
  • 00:03:36
    JavaScript Frameworks out there um a new
  • 00:03:39
    one's probably been invented since we've
  • 00:03:41
    been in this room um but the concepts
  • 00:03:43
    we'll cover today should apply fairly
  • 00:03:45
    universally uh the implementation just
  • 00:03:48
    might vary between framework uh in this
  • 00:03:50
    talk I'll be showing a mix of code
  • 00:03:52
    samples from both View and react um just
  • 00:03:55
    because those are the Frameworks that
  • 00:03:56
    I'm most familiar with but um like I
  • 00:03:58
    said most of the concept
  • 00:04:00
    um are applicable to all of
  • 00:04:03
    them and web accessibility is a big and
  • 00:04:06
    Broad topic um but today we're going to
  • 00:04:08
    focus on things that are generally
  • 00:04:10
    within the control of the developer um
  • 00:04:13
    and things that give the highest amount
  • 00:04:15
    of impact for the lowest amount of
  • 00:04:17
    effort some of the things we'll cover
  • 00:04:19
    today are simple and they are easy but
  • 00:04:23
    and they could be considered low hanging
  • 00:04:24
    fruit but low hanging does not mean low
  • 00:04:28
    impact uh some of the most basic changes
  • 00:04:30
    we can make to our applications can be
  • 00:04:32
    the difference between usable and
  • 00:04:35
    unusable before we dive into much I just
  • 00:04:38
    want to take a moment to set a shared
  • 00:04:40
    understanding of what we mean when we
  • 00:04:42
    talk about making something
  • 00:04:44
    accessible I think the simplest
  • 00:04:46
    definition is that web accessibility is
  • 00:04:48
    the practice of removing barriers to
  • 00:04:51
    using your website so making it easier
  • 00:04:54
    for people with disabilities to consume
  • 00:04:56
    your content to buy your product to
  • 00:04:59
    complete the actions they came to do and
  • 00:05:01
    get on with their day but accessibility
  • 00:05:04
    doesn't only benefit people with
  • 00:05:06
    disabilities it benefits all of us a lot
  • 00:05:08
    of the things we take for granted today
  • 00:05:10
    were first built for people with
  • 00:05:12
    disabilities so for example Speech to
  • 00:05:15
    Text uh SMS automatic doors and audio
  • 00:05:18
    books were all uh designed for people
  • 00:05:21
    with
  • 00:05:22
    disabilities so when we design uh and
  • 00:05:25
    build our code uh to be accessible for
  • 00:05:27
    people with disabilities we also o help
  • 00:05:30
    people are experiencing a temporary or
  • 00:05:32
    situational impairment so subtitles help
  • 00:05:35
    both your heart of hearing and de users
  • 00:05:39
    uh as well as people who are in a loud
  • 00:05:41
    environment sufficient color contrast
  • 00:05:43
    helps both your low vision users as well
  • 00:05:45
    as people who are trying to use their
  • 00:05:46
    phone in bright
  • 00:05:49
    sunlight around the web you might hear
  • 00:05:52
    accessibility referred to with the
  • 00:05:53
    acronym alley uh this term was coined
  • 00:05:57
    because there are 11 letters between the
  • 00:05:59
    a and the Y and accessibility I always
  • 00:06:02
    forget to how to spell it this is really
  • 00:06:03
    helpful for me um but also it's a bit of
  • 00:06:05
    a mouthful to
  • 00:06:07
    say uh according to the Australian
  • 00:06:10
    Bureau of Statistics there were around
  • 00:06:12
    4.4 million Australians living with
  • 00:06:15
    disability in 2018 so that's around 177%
  • 00:06:19
    of our population or a little over one
  • 00:06:21
    in
  • 00:06:22
    six and I'm sure no one in this room
  • 00:06:25
    wants to be alienating up to 17% of
  • 00:06:27
    their users you wouldn't be here in this
  • 00:06:29
    room if you did so let's just do a quick
  • 00:06:31
    run through of the broad categories of
  • 00:06:33
    disabilities we want to think about when
  • 00:06:35
    we're creating our
  • 00:06:37
    platforms the most well-known is
  • 00:06:39
    probably visual you might think of blind
  • 00:06:41
    users uh 285 million people worldwide
  • 00:06:45
    have some kind of vision impairment um
  • 00:06:47
    so from Full blindness to lower tunnel
  • 00:06:50
    vision or even color
  • 00:06:53
    blindness uh there's auditory
  • 00:06:55
    disabilities uh one in six Australians
  • 00:06:57
    are affected by some level of hearing
  • 00:06:59
    impairments this can uh be as much as
  • 00:07:02
    profound deafness or even lower levels
  • 00:07:04
    of hearing loss um personally I'm
  • 00:07:07
    actually included in that one in six I
  • 00:07:09
    thought my kids were just mumbling all
  • 00:07:11
    the time um but it turns out I actually
  • 00:07:13
    have permanent hearing loss um most
  • 00:07:16
    likely from listening to very loud heavy
  • 00:07:18
    metal music in my
  • 00:07:20
    youth um it's only the high upper
  • 00:07:23
    frequencies I'm missing um but those
  • 00:07:26
    frequencies are really important for um
  • 00:07:28
    deciphering speech so it means I can
  • 00:07:31
    have trouble understanding people in
  • 00:07:32
    loud environments um you can't whisper
  • 00:07:35
    secrets to me um and captions and
  • 00:07:37
    subtitles are my
  • 00:07:39
    friend another broad category is U motor
  • 00:07:43
    impairments this includes a wide range
  • 00:07:46
    of conditions that can affect a person's
  • 00:07:48
    physical ability from loss of Limbs to
  • 00:07:51
    Chronic arthritis or cerebal
  • 00:07:53
    posy this group uses the widest range of
  • 00:07:57
    assistive Technologies to access the web
  • 00:07:59
    so that could include things like voice
  • 00:08:01
    recognition software eye tracking head
  • 00:08:03
    ones and adaptive keyboards to name a
  • 00:08:07
    few and the last broad category is uh
  • 00:08:10
    cognitive so these are disabilities that
  • 00:08:12
    aair a person's memory attention uh
  • 00:08:16
    learning perceptions or thoughts uh it
  • 00:08:19
    includes conditions like intellectual
  • 00:08:20
    impairments neurodevelopmental disorders
  • 00:08:23
    and
  • 00:08:25
    dementia and you might have noticed that
  • 00:08:27
    a number of the conditions I've
  • 00:08:28
    mentioned are commonly found in people
  • 00:08:30
    as we age and if we're lucky we're all
  • 00:08:33
    going to be old someday so visual and
  • 00:08:35
    hearing deterioration plus physical and
  • 00:08:38
    mental decline are all expected as we
  • 00:08:40
    get older and I don't know about you but
  • 00:08:42
    as a millennial I don't plan to stop
  • 00:08:44
    using the web just because I get old so
  • 00:08:46
    let's all be kind to our future selves
  • 00:08:48
    as
  • 00:08:50
    well if you've ever needed to make your
  • 00:08:53
    website or app compliant which is pretty
  • 00:08:55
    common if you work in the government or
  • 00:08:57
    banking or health space
  • 00:09:00
    you may have heard of the web content
  • 00:09:02
    accessibility
  • 00:09:03
    guidelines um it's often referred to by
  • 00:09:05
    its acronym wiag um these are a set of
  • 00:09:08
    guidelines created by the worldwide Web
  • 00:09:10
    Consortium in 1995 they've been updated
  • 00:09:13
    a few times since then um the latest
  • 00:09:15
    version 2.2 was just released uh late
  • 00:09:18
    last year uh and these are technical
  • 00:09:20
    standards which platforms are measured
  • 00:09:22
    against when being assessed for
  • 00:09:24
    accessibility or when they're being sued
  • 00:09:26
    for lack of accessibility
  • 00:09:30
    the guidelines are a list of success
  • 00:09:32
    criteria to meet with in-depth technical
  • 00:09:34
    documentation on how to meet them it is
  • 00:09:37
    not a light bedtime read um it but it is
  • 00:09:40
    an excellent reference if you want to
  • 00:09:42
    Deep dive on a specific requirement uh
  • 00:09:45
    and different techniques on how to meet
  • 00:09:47
    the requirement and and don't worry I
  • 00:09:49
    know this looks super daunting um but
  • 00:09:51
    there are like plenty of resources out
  • 00:09:53
    there that sort of break this down into
  • 00:09:55
    sizable easy to understand chunks um and
  • 00:09:58
    I'll link to some of those at the end in
  • 00:10:00
    my
  • 00:10:02
    resources so wiag is broken down into
  • 00:10:04
    four main principles um and often
  • 00:10:08
    referred to with the acronym of
  • 00:10:10
    poor P stands for perceivable so this
  • 00:10:13
    means that information is presented in a
  • 00:10:15
    way that can be accessed or transformed
  • 00:10:18
    for the different sensors so for example
  • 00:10:21
    a video having captions uh or the text
  • 00:10:24
    added to the page as HTML instead of an
  • 00:10:26
    image of text so assisted technology can
  • 00:10:29
    read it
  • 00:10:30
    out the second principle is operable so
  • 00:10:33
    this just means your interface can be
  • 00:10:35
    fully operated in multiple ways not just
  • 00:10:37
    a single method like a
  • 00:10:39
    mouse uh so examples of this include
  • 00:10:42
    like a drag and drop interface um that
  • 00:10:44
    also has keyboard controls or an app
  • 00:10:46
    with a shake to win functionality that
  • 00:10:48
    can also be activated with a
  • 00:10:51
    tap the third principle is
  • 00:10:54
    understandable so this relates to how
  • 00:10:55
    the information is presented and how
  • 00:10:57
    clear the functions are examples of this
  • 00:11:00
    are using plain understandable English
  • 00:11:03
    um and written descriptions of
  • 00:11:04
    information contained in charts or
  • 00:11:07
    graphs and the last principle is robust
  • 00:11:10
    so you can think of robust as being
  • 00:11:12
    similar to Progressive enhancement it's
  • 00:11:14
    making sure all your code and
  • 00:11:15
    functionality is supported in a variety
  • 00:11:18
    of older browsers um and systems before
  • 00:11:21
    adding in any optional extra touches and
  • 00:11:24
    each of these Wick a success criteria
  • 00:11:26
    will relate to one of these four
  • 00:11:28
    principles
  • 00:11:30
    wiag also has three levels of adherence
  • 00:11:33
    uh level a this is your must-have bare
  • 00:11:36
    minimum uh so when we don't meet this
  • 00:11:39
    standard uh people with disabilities are
  • 00:11:41
    likely to have trouble accessing your
  • 00:11:44
    application or having trouble using
  • 00:11:46
    it uh double A so this is generally what
  • 00:11:50
    we aim for as an industry when we meet
  • 00:11:52
    this level most people with disabilities
  • 00:11:54
    will be able to adjust their settings to
  • 00:11:57
    be able to use your application fairly
  • 00:11:58
    comfortably
  • 00:12:01
    uh and level AAA this is the highest and
  • 00:12:03
    strictest standard of accessibility it's
  • 00:12:06
    recommended when your primary audience
  • 00:12:08
    is people with specific disabilities so
  • 00:12:10
    throughout this talk I'm going to
  • 00:12:12
    reference the specific wi ey criteria
  • 00:12:14
    that applies to the technique we're
  • 00:12:20
    discussing so to kick off we're going to
  • 00:12:23
    start with HTML because meaningful
  • 00:12:26
    markup is the foundation of an
  • 00:12:27
    accessible website you know when I said
  • 00:12:30
    at the beginning that HTML is pretty
  • 00:12:32
    accessible out of the box well that's
  • 00:12:36
    half true it is when we use the right
  • 00:12:38
    HTML elements unfortunately good HTML
  • 00:12:42
    has become a bit of a lost art in the
  • 00:12:44
    days of JavaScript engineering um but
  • 00:12:46
    getting back to these Basics will give
  • 00:12:48
    us the biggest bang for our buck in
  • 00:12:50
    making an accessible
  • 00:12:52
    app meaningful or semantic markup it
  • 00:12:56
    simply means the using the native
  • 00:12:59
    browser elements and controls to convey
  • 00:13:01
    the meaning purpose and structure of our
  • 00:13:04
    content if you saw Mandy's excellent
  • 00:13:06
    talk on Wednesday you'll know that HTML
  • 00:13:09
    was designed with built-in meaning and
  • 00:13:13
    functionality and to understand why the
  • 00:13:15
    correct HTML is so important it's
  • 00:13:18
    helpful to understand how a screen
  • 00:13:20
    reader user uh navigates a web page so
  • 00:13:24
    just as cited users can scan a site uh
  • 00:13:27
    to quickly get the relevant information
  • 00:13:29
    inform screen reader users can do a
  • 00:13:31
    similar
  • 00:13:32
    thing they can use what's called a rotor
  • 00:13:35
    inside the screen reader to create lists
  • 00:13:37
    of different information within a page
  • 00:13:40
    cycle through them and navigate to
  • 00:13:42
    specific items quickly for example a
  • 00:13:45
    list of all the headings on a page uh or
  • 00:13:48
    all of the links or buttons or Landmark
  • 00:13:51
    roles but if we haven't use HTML in the
  • 00:13:54
    way it's designed we actually remove
  • 00:13:56
    that ability so people are forced to
  • 00:13:58
    read out the ENT High web page to find
  • 00:14:00
    what they're looking
  • 00:14:02
    for another group that can be affected
  • 00:14:05
    by non-semantic markup are keyboard
  • 00:14:07
    users uh when we use elements that don't
  • 00:14:09
    have the appropriate accessibility
  • 00:14:11
    features built in we can prevent
  • 00:14:13
    keyboard users from being able to access
  • 00:14:15
    and activate those web
  • 00:14:17
    controls and accessibility isn't the
  • 00:14:19
    only benefit you'll get from using HTML
  • 00:14:22
    correctly it's great for SEO as well
  • 00:14:25
    assisted Technologies access your page
  • 00:14:27
    in a similar way to search engine
  • 00:14:29
    crawlers relying on the contextual
  • 00:14:31
    information provided by the markup so
  • 00:14:34
    for example interpreting that a H1 is
  • 00:14:36
    the most important content on the page
  • 00:14:38
    or that the text within an anchor limit
  • 00:14:40
    anchor element describes the purpose and
  • 00:14:43
    relationship of that
  • 00:14:44
    link if a screen reader doesn't
  • 00:14:47
    understand your content there's a good
  • 00:14:49
    chance that Google can't
  • 00:14:51
    either so here we've got an example of a
  • 00:14:55
    uh inaccessible card component and I'm
  • 00:14:57
    sure we've all seen markup like like
  • 00:14:59
    this before we've got a rapid div for
  • 00:15:01
    styling a heading div a paragraph div a
  • 00:15:05
    button
  • 00:15:06
    div this is what we affectionately call
  • 00:15:09
    div soup uh and it's not just divs that
  • 00:15:12
    are a problem uh in modern web
  • 00:15:14
    development we've been given this great
  • 00:15:16
    power to create custom human readable
  • 00:15:19
    elements or components and what do we
  • 00:15:23
    know comes with great
  • 00:15:27
    power great respon
  • 00:15:29
    responsibility so yes we can create a
  • 00:15:32
    JavaScript component called totally
  • 00:15:33
    awesome button but that doesn't mean we
  • 00:15:35
    always should because these custom
  • 00:15:37
    elements have the same effect as uh
  • 00:15:39
    using Gibs they have no default meaning
  • 00:15:42
    and don't pass any contextual
  • 00:15:43
    information to the accessibility tree
  • 00:15:45
    unless we add it ourselves so we just
  • 00:15:47
    need to ensure we're using appro
  • 00:15:49
    appropriate HTML elements inside of our
  • 00:15:51
    custom
  • 00:15:53
    components so here we've got a more
  • 00:15:55
    accessible version of our card component
  • 00:15:57
    where we've replaced the R A div with a
  • 00:15:59
    list item so we can logically group this
  • 00:16:02
    card with the other cards surrounding it
  • 00:16:04
    we've replaced the heading div with a H2
  • 00:16:07
    element so this will now appear in a
  • 00:16:08
    screen readers list of uh headings for
  • 00:16:11
    easier navigation we're now using a real
  • 00:16:14
    paragraph uh and a real HTML button
  • 00:16:17
    element and so let's just take a moment
  • 00:16:19
    to uh talk about HTML buttons they're
  • 00:16:23
    actually really amazing and Powerful so
  • 00:16:25
    by default they're focusable by the
  • 00:16:27
    keyboard they can submit data to a
  • 00:16:30
    server and reset forms they can be
  • 00:16:32
    disabled by the disabled attribute and
  • 00:16:35
    styled by their active focus and hover
  • 00:16:37
    States and they their role is
  • 00:16:39
    automatically reported to the
  • 00:16:40
    accessibility tree so let's take a look
  • 00:16:43
    at what we need to do to make our button
  • 00:16:45
    div accessible first we need to make it
  • 00:16:48
    FOC focusable with the keyboard because
  • 00:16:49
    divs aren't focusable by
  • 00:16:51
    default then we need to give it a roll
  • 00:16:53
    of button so assist of Technologies no
  • 00:16:56
    uh can announce it as a button without
  • 00:16:58
    this us screen read user may not know
  • 00:17:00
    that this element is meant to be
  • 00:17:02
    interacted with we'll need to add a key
  • 00:17:05
    up or key down listener because divs
  • 00:17:06
    have no synthetic click activation and
  • 00:17:09
    then we also need to code JavaScript
  • 00:17:11
    Handler to perform whatever action
  • 00:17:13
    clicking would do uh and so we could do
  • 00:17:16
    all this or we could use a HTML button
  • 00:17:19
    and get that behavior built in for free
  • 00:17:22
    so next time you need an element to do
  • 00:17:24
    something like trigger a popup menu open
  • 00:17:26
    a motal window toggle an interface a
  • 00:17:30
    button is probably the right
  • 00:17:33
    choice using HTML using appropriate HTML
  • 00:17:38
    uh touches on a number of Wick a success
  • 00:17:40
    criteria including info and
  • 00:17:42
    relationships so this is about all the
  • 00:17:44
    information that is conveyed visually so
  • 00:17:47
    like heading styling um is also conveyed
  • 00:17:51
    programmatically uh keyboard so this is
  • 00:17:53
    uh pretty straightforward just saying
  • 00:17:55
    that anything that you can do with a
  • 00:17:56
    mouse you can also achieve with a
  • 00:17:58
    keyboard
  • 00:17:59
    and name roll value so this criteria
  • 00:18:01
    relates to making sure interface
  • 00:18:03
    components have a a name and role that
  • 00:18:05
    can be programmatically redetermined
  • 00:18:07
    which is what we were talking about with
  • 00:18:08
    the button a moment ago um and you might
  • 00:18:11
    notice that these are all level a
  • 00:18:13
    criteria so they are really
  • 00:18:17
    critical next let's talk about
  • 00:18:21
    forms the internet is full of forms
  • 00:18:24
    newsletter subscriptions contact forms
  • 00:18:27
    product signups shopping carts you might
  • 00:18:30
    notice that these are a lot of things
  • 00:18:31
    that make your company money so
  • 00:18:35
    important there are number of ways we
  • 00:18:37
    can make our forms more accessible um
  • 00:18:39
    the first I want to talk to about
  • 00:18:41
    relates to form form inputs and labels
  • 00:18:44
    and I can break it down into two simple
  • 00:18:47
    easy rules to remember inputs must have
  • 00:18:50
    labels and those labels must be
  • 00:18:53
    linked here we've got a visible label
  • 00:18:55
    which is always a good start but the
  • 00:18:57
    label and the aren't actually linked in
  • 00:19:00
    anyway so this means when a screen
  • 00:19:01
    reader lands in the input the label is
  • 00:19:03
    not announced so the screen reader will
  • 00:19:06
    say edit text blank they'll know they're
  • 00:19:09
    inside a text input but it's not clear
  • 00:19:11
    what that text field is actually
  • 00:19:14
    for contrast this with an explicitly
  • 00:19:17
    linked label uh we do this by adding a
  • 00:19:19
    four attribute to the label and matching
  • 00:19:22
    ID on the input and when a screen reader
  • 00:19:24
    lands in this input the label will
  • 00:19:26
    announc edit text Lego character so it's
  • 00:19:29
    now clear to the user what the input is
  • 00:19:32
    asking
  • 00:19:33
    for now I did say that the IDS must be
  • 00:19:37
    unique on a page so one of the reasons
  • 00:19:39
    we all love single page apps is being
  • 00:19:41
    able to create and reuse modular
  • 00:19:43
    components but this also means you won't
  • 00:19:46
    always know what other inputs are or
  • 00:19:48
    forms are going to be appearing on the
  • 00:19:50
    same page so if your idea is something
  • 00:19:52
    fairly generic like address or name it
  • 00:19:55
    may not be the only address or name on
  • 00:19:58
    the page
  • 00:20:00
    um so we can get around this uh by
  • 00:20:03
    importing a package like uu ID which
  • 00:20:06
    generates unique identifiers for us uh
  • 00:20:09
    we can create a variable that contain
  • 00:20:11
    that combines a human readable name like
  • 00:20:13
    address with a unique identifier suffix
  • 00:20:16
    and then pass that variable into the
  • 00:20:18
    label and input to ensure there won't be
  • 00:20:20
    any duplicates with other inputs on the
  • 00:20:24
    page and you might be aware of another
  • 00:20:26
    approach where a label can be linked
  • 00:20:28
    implicit
  • 00:20:29
    uh this is achieved by wrapping the
  • 00:20:31
    input inside of the label and that does
  • 00:20:34
    sound a lot more straightforward um
  • 00:20:37
    however this method doesn't have as good
  • 00:20:38
    support with aist of Technologies so
  • 00:20:41
    it's always best to explicitly link if
  • 00:20:43
    it's
  • 00:20:44
    possible and so what if you've been
  • 00:20:46
    given a design and it doesn't actually
  • 00:20:48
    have visible labels this can be a
  • 00:20:50
    problem for people who use screen
  • 00:20:52
    readers as well as people with cognitive
  • 00:20:54
    impairments who might not be able to
  • 00:20:55
    infer the information from the context
  • 00:20:58
    it was was really common to see about 10
  • 00:21:00
    years ago and thankfully we don't see
  • 00:21:02
    this as much now but it does still
  • 00:21:03
    happen not all designers are aware of
  • 00:21:06
    how important visible labels are for
  • 00:21:09
    accessibility so first thing I would say
  • 00:21:11
    is have a chat with your designer most
  • 00:21:13
    designers are very reasonable they want
  • 00:21:15
    to have the best experience for their
  • 00:21:17
    users um so they'll probably be pretty
  • 00:21:20
    happy um once they once they know how
  • 00:21:22
    important it is um to add those in but
  • 00:21:25
    if for some reason you're getting a lot
  • 00:21:27
    of push back or it's not possible for
  • 00:21:29
    some reason have visible labels you as
  • 00:21:31
    the developer still have um the power to
  • 00:21:34
    make this more
  • 00:21:35
    accessible so we can add a label into
  • 00:21:38
    the HTML that is assist accessible to
  • 00:21:41
    syst of Technology uh while hiding it
  • 00:21:44
    visually with CSS um if you're using a
  • 00:21:47
    CSS Library like Tailwind or bootstrap
  • 00:21:50
    um they already have a built-in utility
  • 00:21:52
    class for this purpose um and if not you
  • 00:21:55
    can easily roll your own the CSS on
  • 00:21:57
    screen is a common method of doing this
  • 00:22:00
    uh it uses a combination of absolute
  • 00:22:02
    positioning uh fixed height and width
  • 00:22:04
    overflow and clip path uh it just moves
  • 00:22:07
    the content offscreen um without
  • 00:22:09
    affecting other elements um on the page
  • 00:22:12
    and will still be announced by a screen
  • 00:22:14
    reader including labels meets the wiag
  • 00:22:17
    success criteria of labels and
  • 00:22:19
    instructions and again you might notice
  • 00:22:21
    that this is a level a
  • 00:22:24
    criteria and you might be wondering
  • 00:22:25
    about placeholder text and if there are
  • 00:22:27
    valid alternative to labels
  • 00:22:30
    unfortunately I'm sorry to say they are
  • 00:22:32
    not placeholders are popular because
  • 00:22:35
    they save space and they're minimalist
  • 00:22:37
    however they're not accessible for a
  • 00:22:39
    range of disabilities they're not
  • 00:22:40
    reliably supported by different assisted
  • 00:22:43
    Technologies so they may not be
  • 00:22:44
    announced to the user and they can be
  • 00:22:47
    problematic for people with cognitive
  • 00:22:48
    impairments uh who can forget what the
  • 00:22:50
    prompt was when they click in and it
  • 00:22:53
    disappears they rarely have sufficient
  • 00:22:55
    color contrast uh for people with visual
  • 00:22:58
    impairment
  • 00:22:59
    but if we increase that color contrast
  • 00:23:02
    uh then we make a situation where the
  • 00:23:04
    users might mistake the input as already
  • 00:23:07
    being filled in um increasing the
  • 00:23:09
    likelihood of submission errors and
  • 00:23:11
    frustration from the user and this would
  • 00:23:13
    be especially true of anyone who might
  • 00:23:15
    be using um high contrast
  • 00:23:18
    modes and so all of these reasons are
  • 00:23:20
    also why we shouldn't be relying on
  • 00:23:22
    placeholders for helper text helper text
  • 00:23:25
    provides more information to users on
  • 00:23:27
    how they fill out a specific spefic
  • 00:23:28
    field but if the information is
  • 00:23:31
    important enough to be included on the
  • 00:23:33
    page it should be permanently visible
  • 00:23:35
    and available to assist of tech by
  • 00:23:37
    including in a paragraph text below the
  • 00:23:40
    label which criteria this comes under
  • 00:23:42
    does depend on the context so if not
  • 00:23:45
    following the the helper text um is
  • 00:23:48
    going to give the user a form validation
  • 00:23:50
    error so for example this field only
  • 00:23:52
    accepts nine digits that would come
  • 00:23:54
    under labels or instructions um but if
  • 00:23:57
    we're simply offering guidance on how
  • 00:23:59
    the user can get a better experience but
  • 00:24:01
    it won't stop them submitting the form
  • 00:24:04
    this comes under the AAA criteria of
  • 00:24:06
    help an example of that is when you're
  • 00:24:09
    saying suggestions on how to write a
  • 00:24:11
    good profile bio to increase the
  • 00:24:14
    users uh chance of a successful
  • 00:24:18
    match another benefit of linking your
  • 00:24:20
    labels and your inputs is that it
  • 00:24:22
    increases the size of the touch Target
  • 00:24:25
    the touch Target when not linked is just
  • 00:24:27
    the input itself so think a small radio
  • 00:24:30
    button or check
  • 00:24:31
    boox but when we link our labels at our
  • 00:24:33
    inputs that touch Target then increases
  • 00:24:36
    uh so that now includes all of the label
  • 00:24:39
    area as well so imagine you're a
  • 00:24:41
    passenger in a bumpy car which one would
  • 00:24:43
    you rather be trying to click this
  • 00:24:46
    increased area can make a huge
  • 00:24:47
    difference for people uh that have
  • 00:24:49
    troubl making prec Precision movements
  • 00:24:52
    for example somebody with uh hand
  • 00:24:54
    drummers and this helps us meet true
  • 00:24:57
    success criteria Target size minimum is
  • 00:25:00
    the double A criteria setting out a
  • 00:25:02
    minimum Target of Target size of 24x 24
  • 00:25:05
    pixels and then we also have the more
  • 00:25:07
    strict AAA criteria which sets out a
  • 00:25:10
    minimum touch Target of 44x 44
  • 00:25:13
    pixels another way we can make our form
  • 00:25:16
    inputs more accessible is by enabling
  • 00:25:18
    auto complete we can do this by adding
  • 00:25:21
    the HML auto complete attribute to the
  • 00:25:24
    input and this encourages browsers to
  • 00:25:27
    autofill known ANS anwers and it can
  • 00:25:29
    also allow assistive Tech to customize
  • 00:25:31
    the display for example showing familiar
  • 00:25:33
    icons next to input builds to help users
  • 00:25:36
    that might have difficulty reading like
  • 00:25:38
    a birthday cake could be shown uh in
  • 00:25:40
    front of an input with an auto complete
  • 00:25:42
    of
  • 00:25:43
    birthday and this helps us meet success
  • 00:25:46
    criteria identify input
  • 00:25:49
    [Music]
  • 00:25:53
    purpose next we'll talk about uh visible
  • 00:25:56
    Focus styles
  • 00:25:58
    Focus indicators are the Styles applied
  • 00:26:01
    uh to interactive elements when they
  • 00:26:02
    receive a user's Focus to show where
  • 00:26:04
    they are on a page they help sided
  • 00:26:07
    people that are using a keyboard or a
  • 00:26:09
    voice input or some other method that's
  • 00:26:11
    not a mouse and they can help people
  • 00:26:13
    with attention or memory issues that may
  • 00:26:15
    get distracted and then have to come
  • 00:26:17
    back each browser comes with its own
  • 00:26:20
    default Focus style uh it's often a
  • 00:26:22
    thick blue outline but uh this will vary
  • 00:26:24
    depending on the operating system and
  • 00:26:26
    the device that you're using
  • 00:26:29
    ever since CSS resets became popular um
  • 00:26:32
    in the mid 2000s there's been a tendency
  • 00:26:34
    to remove the these defaults for
  • 00:26:37
    consistency uh between browsers but also
  • 00:26:39
    because they're considered ugly but
  • 00:26:42
    removing the focus outline entirely is
  • 00:26:44
    like removing a wheelchair ramp because
  • 00:26:46
    it doesn't fit with the
  • 00:26:47
    aesthetic when we remove these Focus
  • 00:26:50
    indicators uh sighted people not using a
  • 00:26:52
    mouse can get lost imagine you were
  • 00:26:55
    navigating a retail website searching
  • 00:26:57
    for a specific specific item and your
  • 00:26:59
    mouse pointer just disappeared and to
  • 00:27:01
    make it more difficult there were no
  • 00:27:03
    hover styles on any of the links or
  • 00:27:04
    buttons that's a similar to the
  • 00:27:07
    experience of cited keyboard user when
  • 00:27:09
    the focus indicators are missing it's a
  • 00:27:11
    really confusing experience and there's
  • 00:27:13
    no way of knowing when you're where you
  • 00:27:15
    are on the page or what link or button
  • 00:27:17
    would uh be executed if you hit
  • 00:27:21
    enter so instead of removing the focus
  • 00:27:23
    outlines entirely we can replace the
  • 00:27:26
    default Focus styles with our own on
  • 00:27:28
    brand styles with the focus visible
  • 00:27:30
    pseudo class Focus visible only applies
  • 00:27:33
    Styles when the browser thinks it makes
  • 00:27:35
    sense to based on some heuristics it
  • 00:27:37
    determines like a non-pointer input
  • 00:27:40
    being
  • 00:27:41
    used wiang success criteria Focus
  • 00:27:44
    visible states that uh any interface
  • 00:27:47
    operable with a keyboard must have a
  • 00:27:49
    focus indicator that's visible but it
  • 00:27:51
    doesn't actually set out any rules
  • 00:27:52
    around how that indicator is styled uh
  • 00:27:55
    the non-text contrast does specify a 3:1
  • 00:27:59
    contrast ratio for interactive
  • 00:28:01
    components and their um different states
  • 00:28:04
    but technically you could meet that
  • 00:28:06
    criteria by a subtle change in like
  • 00:28:08
    background color as long as that state
  • 00:28:12
    um has contrast with its background but
  • 00:28:15
    that could still be really easy to miss
  • 00:28:17
    so in uh the latest wiag 2.2 um they did
  • 00:28:21
    add a new criteria specifically to
  • 00:28:24
    address the focus indicator appearance
  • 00:28:26
    in relation to its non Focus State um
  • 00:28:29
    this is a AAA criteria so may not
  • 00:28:31
    technically be required for your
  • 00:28:33
    compliance but it's a really great
  • 00:28:34
    guideline on the best practice um and
  • 00:28:37
    how you can help a range of users and
  • 00:28:39
    that criteria defines a minimum level of
  • 00:28:41
    visibility for both size and contrast
  • 00:28:44
    but it kind of boils down to make it big
  • 00:28:47
    make it sound out the criteria says the
  • 00:28:50
    focus indicator needs to be at least two
  • 00:28:51
    pixels thck uh and it me needs to meet
  • 00:28:53
    the 3:1 color contrast between the
  • 00:28:55
    focused and the unfocused state um and
  • 00:28:58
    although we can use different Focus
  • 00:29:00
    styles on different elements for example
  • 00:29:02
    we could change the background colors on
  • 00:29:04
    buttons and add a border to Links the
  • 00:29:07
    easiest way to achieve this is with an
  • 00:29:09
    outline on everything and outlines are
  • 00:29:11
    great for a couple reasons so they can
  • 00:29:13
    be applied without causing any
  • 00:29:15
    significant changes to those elements um
  • 00:29:18
    which makes them simple to apply across
  • 00:29:20
    a lot of different types of
  • 00:29:22
    elements because the outlines aren't
  • 00:29:25
    part of an element's Box model it won't
  • 00:29:27
    cause any layout shift when we apply it
  • 00:29:30
    and because outlines aren't removed by
  • 00:29:32
    forced color mode like Windows high
  • 00:29:34
    contrast
  • 00:29:37
    um then we won't have the same effect as
  • 00:29:40
    background colors and borders which can
  • 00:29:42
    be
  • 00:29:44
    removed another tip is to use an offset
  • 00:29:47
    um by a few pixels adding an offset
  • 00:29:50
    means we don't have to worry about the
  • 00:29:51
    contrast ratio between the element and
  • 00:29:53
    the outline making it easier to see and
  • 00:29:55
    easier to pass
  • 00:30:02
    the next topic is uh one of the main
  • 00:30:04
    challenges that are really unique to
  • 00:30:06
    single page applications and these are
  • 00:30:09
    they are fundamental differences in how
  • 00:30:11
    routing
  • 00:30:12
    Works in a single page app versus a
  • 00:30:15
    traditional multi-page app when we visit
  • 00:30:17
    a traditional multi-page app the client
  • 00:30:20
    sends a request to the server and the
  • 00:30:22
    server goes to the database and gets the
  • 00:30:24
    content and it builds out the page and
  • 00:30:26
    sends back all the HTML CSS and
  • 00:30:28
    JavaScript your website needs to build
  • 00:30:30
    that
  • 00:30:31
    page when we click a link we basically
  • 00:30:33
    do the whole process again uh so the
  • 00:30:36
    client sends a request to the server
  • 00:30:38
    server builds the whole page app and it
  • 00:30:40
    sends it over to the client and this
  • 00:30:41
    triggers a full page refresh and when
  • 00:30:44
    the page refreshes the page title
  • 00:30:46
    changes and the keyboard focus is reset
  • 00:30:49
    to the top of the page and this triggers
  • 00:30:51
    a screen reading you to announce the new
  • 00:30:53
    information including the new page title
  • 00:30:55
    and the new
  • 00:30:56
    content so contrast this with a single
  • 00:30:59
    page application uh generally in this
  • 00:31:01
    situation the browser sends a request to
  • 00:31:03
    the server the server sends back a
  • 00:31:05
    little bit of HTML and CSS and a whole
  • 00:31:07
    ton of JavaScript and the browser then
  • 00:31:10
    uses all this information to build out
  • 00:31:12
    the page and render
  • 00:31:13
    it when we click on an internal link the
  • 00:31:16
    browser already has most of what it
  • 00:31:18
    needs to build out the new page uh so it
  • 00:31:21
    just asks the server for a little bit of
  • 00:31:22
    data it needs from an
  • 00:31:24
    API the server sends some back some data
  • 00:31:27
    usually in in the form of some Json uh
  • 00:31:29
    and then the browser rebuilds the
  • 00:31:31
    component it needs
  • 00:31:33
    itself so we're only updating uh part of
  • 00:31:36
    the page uh so the shell and that just
  • 00:31:39
    often the header and footer uh Remain
  • 00:31:42
    the page title doesn't change but the
  • 00:31:44
    component the user was on is gone um and
  • 00:31:46
    the user Focus usually just gets dropped
  • 00:31:48
    to whatever's beneath that so a water uh
  • 00:31:52
    and in the case of screen reader users
  • 00:31:53
    it's difficult to know what if anything
  • 00:31:56
    has actually changed
  • 00:31:58
    so we need to recreate a bit of that
  • 00:32:00
    traditional Behavior by updating the
  • 00:32:02
    page title and managing the keyboard
  • 00:32:05
    Focus we'll start with updating the page
  • 00:32:07
    title in single page apps we tend to set
  • 00:32:10
    the value once in the global template
  • 00:32:12
    and then don't really think about it too
  • 00:32:14
    much again and just to be clear we're
  • 00:32:16
    talking about the uh the document title
  • 00:32:18
    that shows in your browser tab uh not
  • 00:32:21
    the page heading within the Mage main
  • 00:32:23
    page content this is the information
  • 00:32:26
    announced by a screen reader when the
  • 00:32:27
    page Lo
  • 00:32:28
    so it gives context of the page we're on
  • 00:32:30
    but it also acts as a confirmation of a
  • 00:32:32
    change in page context so how do we
  • 00:32:35
    update the document page title when the
  • 00:32:36
    page itself isn't actually
  • 00:32:39
    changing one approach is to use life
  • 00:32:41
    cycle methods uh in combination with
  • 00:32:43
    vanilla JavaScript uh so in a react
  • 00:32:45
    functional component we might use the
  • 00:32:47
    use effect hook uh in view we might use
  • 00:32:50
    the mounted life cycle hook uh and
  • 00:32:53
    another way we can do this in view is
  • 00:32:55
    with its official router view router
  • 00:32:57
    gives us the ability to specify our page
  • 00:33:00
    meta values at the time we Define the
  • 00:33:02
    routes uh and it also has a powerful
  • 00:33:05
    feature called navigation guards which
  • 00:33:07
    are functions that automatically get
  • 00:33:08
    called before or after navigation to a
  • 00:33:10
    route and so in this code we use the
  • 00:33:12
    before each uh guard to set the document
  • 00:33:15
    title to be passed in uh to pass in The
  • 00:33:18
    Meta title or a sensible default if we
  • 00:33:20
    haven't passed anything
  • 00:33:22
    in another approach to updating your
  • 00:33:24
    document title um is using a package
  • 00:33:26
    like react helmet or view meta you might
  • 00:33:29
    consider an approach like this if you
  • 00:33:30
    have a lot of meta tags that need
  • 00:33:32
    updating so for example if you've got a
  • 00:33:34
    marketing website um maybe that needs
  • 00:33:37
    information from a headless CMS to
  • 00:33:39
    update a whole bunch of social media or
  • 00:33:41
    search engine tags you might consider
  • 00:33:43
    that
  • 00:33:45
    approach updating the page title assist
  • 00:33:47
    screen reader users to know where they
  • 00:33:50
    are but it's also helpful for people
  • 00:33:51
    with cognitive disabilities and people
  • 00:33:54
    that tend to have multiple tabs open at
  • 00:33:56
    a Time Imagine you had all these
  • 00:33:58
    different email tabs open but the title
  • 00:34:00
    was the same on each one it would be
  • 00:34:02
    really difficult to remember which tab
  • 00:34:04
    was for which
  • 00:34:06
    content and so accurate and meaningful
  • 00:34:09
    page titles uh is required under the wio
  • 00:34:12
    criteria page title again a a single a
  • 00:34:17
    level um so the other one we wanted to
  • 00:34:19
    talk about was the focus management uh
  • 00:34:21
    and focus management is when we
  • 00:34:23
    dynamically control a users keyboard
  • 00:34:25
    Focus programmatically so this should
  • 00:34:27
    only be used sparingly um and generally
  • 00:34:30
    only in response to a user's
  • 00:34:32
    action when a user clicks a link to
  • 00:34:35
    navigate to a new route that's a time
  • 00:34:37
    when uh it does make sense to actively
  • 00:34:39
    manage where that keyboard focus is
  • 00:34:41
    going
  • 00:34:42
    to and so there's two sort of common
  • 00:34:45
    strategies here to consider um the first
  • 00:34:47
    is to simulate a traditional page load
  • 00:34:49
    by faking a regular page navigation um
  • 00:34:52
    and that includes announcing the page to
  • 00:34:54
    using a live region and setting focus on
  • 00:34:56
    the body element
  • 00:34:58
    uh the second option takes an approach
  • 00:35:00
    that's a little more natural to the
  • 00:35:02
    single page app Paradigm uh instead of
  • 00:35:04
    making the application behave as a
  • 00:35:06
    traditional app we can make the single
  • 00:35:08
    page app more user friendly by setting
  • 00:35:10
    Focus to where we know the user wants to
  • 00:35:12
    go which is the new
  • 00:35:15
    content uh there isn't a hard right or
  • 00:35:17
    wrong choice here um but re user
  • 00:35:19
    research by the Gatsby team suggests
  • 00:35:21
    that option two is a little more
  • 00:35:23
    intuitive for a broader group of users
  • 00:35:25
    with disabilities so that's what we're
  • 00:35:27
    going to go for this example and I'll
  • 00:35:29
    link to their blog post about that in my
  • 00:35:32
    resources as
  • 00:35:33
    well now not all elements can receive
  • 00:35:36
    focus by default generally it's limited
  • 00:35:39
    to like links buttons form inputs um but
  • 00:35:41
    we can manipulate the focus ability of
  • 00:35:43
    an element using tab index and tab index
  • 00:35:46
    has three possible States a tab index of
  • 00:35:49
    zero uh makes an element reachable by
  • 00:35:52
    the keyboard in the order it appears in
  • 00:35:54
    the
  • 00:35:54
    Dom uh a tab index of uh negative uh
  • 00:35:58
    removes the item from the normal Focus
  • 00:36:00
    order if it was in the normal Focus
  • 00:36:02
    order um and it also allows us to send
  • 00:36:04
    Focus to it if it's not normally
  • 00:36:07
    focusable the last possible state is an
  • 00:36:10
    index of greater than zero so one or
  • 00:36:12
    five 10 um this jumps the item in front
  • 00:36:15
    of the other items in the normal tab
  • 00:36:17
    order inserts it into the order um and
  • 00:36:20
    this is pretty much never a good idea so
  • 00:36:23
    it's generally an i pattern I recommend
  • 00:36:26
    you don't do it but I just mentioned it
  • 00:36:27
    here for
  • 00:36:29
    completeness the Gatsby research uh
  • 00:36:31
    suggests there's a few different places
  • 00:36:32
    we could send Focus to um including a
  • 00:36:35
    dedicated skip link or page wrappers um
  • 00:36:38
    but for this U I'm just going to use
  • 00:36:40
    page heading as an example because
  • 00:36:41
    that's I think that's the easiest pretty
  • 00:36:43
    much every page has a H1 um it's the
  • 00:36:46
    easiest implementation I think than
  • 00:36:48
    adding an extra thing that wasn't
  • 00:36:49
    already on the page um so to send
  • 00:36:52
    keyboard Focus we're going to need to
  • 00:36:54
    give it a H1 sorry a tab index of
  • 00:36:57
    negative one because we want it to be
  • 00:36:59
    focusable but we don't want it to appear
  • 00:37:01
    in the tab
  • 00:37:02
    order we use the react hook use ref to
  • 00:37:05
    add a reference to The Heading uh and
  • 00:37:07
    then we use uh the hook use effect to
  • 00:37:10
    set focus on the H1 when the component
  • 00:37:14
    mounts now headings aren't normally
  • 00:37:16
    focusable and it's not standard for
  • 00:37:18
    elements to receive focus on page load
  • 00:37:20
    so having a visible Focus indicator in
  • 00:37:23
    this instance is probably going to be a
  • 00:37:25
    bit confusing um and I'll admit it
  • 00:37:28
    doesn't look amazing either um so this
  • 00:37:30
    is one of those rare times it is okay to
  • 00:37:32
    remove the visible
  • 00:37:35
    Focus another time we need to actively
  • 00:37:38
    manage the users focus is when we're
  • 00:37:40
    working with
  • 00:37:42
    models when we develop models we need to
  • 00:37:45
    do three things when the model opens we
  • 00:37:49
    need to move keyboard Focus to it and
  • 00:37:52
    while the model is open we need to trap
  • 00:37:54
    keyboard Focus within it so keyboard
  • 00:37:56
    users can't access any outside or behind
  • 00:37:59
    the modal and when the user closes the
  • 00:38:01
    model we need to return keyboard Focus
  • 00:38:04
    to where it came
  • 00:38:05
    from years ago uh Rob Dudson who is our
  • 00:38:09
    former Google employee with a fantastic
  • 00:38:11
    accessibility series on YouTube wrote
  • 00:38:14
    modals are actually the boss battle at
  • 00:38:16
    the end of
  • 00:38:17
    accessibility and he was he was on to
  • 00:38:19
    something because until recently making
  • 00:38:21
    a modal accessible was really difficult
  • 00:38:24
    and your best bet was to just use an
  • 00:38:26
    accessibility Focus ready-built plugin
  • 00:38:28
    then try to do it yourself thankfully it
  • 00:38:31
    is a lot easier these days and this is
  • 00:38:33
    thanks to uh improved browser support
  • 00:38:36
    for the native HTML dialogue element
  • 00:38:39
    although dialogue uh was first dropped
  • 00:38:42
    in Chrome in 2014 it took eight years to
  • 00:38:45
    gain support in all of the major
  • 00:38:46
    browsers and so this actually only
  • 00:38:49
    happened in early
  • 00:38:51
    2022 the native uh dialogue element does
  • 00:38:54
    the three things that I already
  • 00:38:55
    mentioned that we need modal to do to be
  • 00:38:58
    accessible right out of the box the
  • 00:39:00
    dialogue is opened using JavaScript
  • 00:39:02
    using the show modal method and closed
  • 00:39:05
    using the close method uh it can also be
  • 00:39:09
    uh closed by hitting the Escape key this
  • 00:39:11
    is a very standard accessibility feature
  • 00:39:13
    expected from keyboard users and we used
  • 00:39:16
    to have to add this in manually but now
  • 00:39:18
    we get it for
  • 00:39:19
    free and the dialogue element also lets
  • 00:39:22
    you configure which element should be
  • 00:39:24
    focused when it opens uh with the
  • 00:39:26
    autofocus attribute
  • 00:39:28
    so by default um it focuses the first
  • 00:39:30
    Focus SCH element in the model but uh
  • 00:39:33
    you might want to customize this for
  • 00:39:34
    your use case for example if the first
  • 00:39:37
    focusable element is a destructive
  • 00:39:39
    action like delete you might want to
  • 00:39:41
    autofocus the Lesser destructive action
  • 00:39:44
    or for example if you've got a modal
  • 00:39:47
    might be T's and c's with an accept
  • 00:39:48
    button and they're supposed to scroll
  • 00:39:50
    through and read the tnc's um you might
  • 00:39:52
    want to send Focus to say the heading
  • 00:39:55
    instead the CL method can also take an
  • 00:39:58
    optional reference to a different return
  • 00:40:01
    element um if there's another element
  • 00:40:03
    that makes more sense but in most cases
  • 00:40:06
    the default is going to be
  • 00:40:08
    suitable the model itself can be styled
  • 00:40:11
    with the pseudo uh selector model uh and
  • 00:40:14
    the everything behind the model can be
  • 00:40:16
    styled with the backdrop pseudo
  • 00:40:20
    element uh if you need to create a
  • 00:40:22
    custom model so if dialog doesn't work
  • 00:40:24
    for you for some reason um it is now
  • 00:40:26
    easier to roll your own accessible
  • 00:40:28
    solution thanks to the introduction of
  • 00:40:30
    anert inert is an HTML attribute that
  • 00:40:33
    disables user input for an element and
  • 00:40:35
    all of its children it also hides
  • 00:40:38
    everything within the element from
  • 00:40:39
    assisted Technologies similar to adding
  • 00:40:41
    an ARA hidden uh or true so this is what
  • 00:40:44
    we can add to the main element of the
  • 00:40:46
    page uh while a custom motor is open to
  • 00:40:49
    ensure that nothing outside or behind it
  • 00:40:51
    can be reached and despite a polyfill
  • 00:40:54
    foret being around for many many years
  • 00:40:56
    it's only recently been added to the
  • 00:40:58
    browsers and this is thanks to all the
  • 00:41:00
    big players working together on shipping
  • 00:41:02
    dialogue which uses an N functionality
  • 00:41:04
    behind the
  • 00:41:05
    scenes and so using these techniques uh
  • 00:41:08
    helps us to meet wiad criteria Focus
  • 00:41:10
    order which says that focusable
  • 00:41:12
    components need to receive order focus
  • 00:41:15
    in an order that preserves meaning and
  • 00:41:19
    operability and so lastly we're going to
  • 00:41:21
    finish up talking about
  • 00:41:24
    testing there's two main categories of
  • 00:41:26
    testing
  • 00:41:28
    uh automated and manual so you'll notice
  • 00:41:33
    uh this is not automated or manual this
  • 00:41:36
    is automated and manual because they're
  • 00:41:38
    both important pieces of the alley
  • 00:41:40
    puzzle we'll start with automated tools
  • 00:41:42
    that are inside our code editor and what
  • 00:41:45
    would a tech talk be at NDC or in 2024
  • 00:41:49
    without mentioning AI so over the last
  • 00:41:52
    year I like many other Engineers have
  • 00:41:54
    been uh triling AI coding assistants and
  • 00:41:57
    GitHub recently shared a prompt you can
  • 00:41:59
    provide their co-pilot to help you with
  • 00:42:01
    accessibility and I'll have a link to
  • 00:42:03
    the article in my resources which
  • 00:42:05
    includes the prompt uh because it's
  • 00:42:07
    really big and really long so don't feel
  • 00:42:10
    like you have to remember it or take a
  • 00:42:12
    screenshot because it'll be in the
  • 00:42:13
    resources so it is a lot um but it does
  • 00:42:16
    follow some pretty standard approaches
  • 00:42:19
    to prompt engineering um so first we
  • 00:42:21
    provide some solid context and
  • 00:42:23
    background to help narrow down the scope
  • 00:42:24
    of solutions uh then we tell co-pilot
  • 00:42:27
    what its role is um and set expectations
  • 00:42:30
    about what kind of feedback we're
  • 00:42:31
    looking for and next we're telling
  • 00:42:34
    co-pilot to reference specific resources
  • 00:42:36
    that we know are reputable and good
  • 00:42:39
    quality uh and then we ask for
  • 00:42:41
    additional resources and reference
  • 00:42:43
    partially so we can learn more also so
  • 00:42:46
    we can verify and double check its
  • 00:42:47
    answers it's given us because we all
  • 00:42:49
    know sometimes AI makes stuff up that
  • 00:42:52
    sounds very
  • 00:42:53
    believable uh and the last one gives a
  • 00:42:55
    final set of requirements reiterates the
  • 00:42:58
    scope that should be considered when
  • 00:42:59
    providing code
  • 00:43:01
    suggestions and if you ever want to
  • 00:43:03
    check that co-pilot is still giving
  • 00:43:05
    answers with this prompt in scope you
  • 00:43:07
    can just ask it to confirm so I have
  • 00:43:10
    used this original um this prompt um and
  • 00:43:13
    I was actually very pleasantly surprised
  • 00:43:15
    at how well it worked everything it told
  • 00:43:17
    me was correct so it uh this is probably
  • 00:43:21
    a tool that would be worth adding to
  • 00:43:23
    Your
  • 00:43:24
    Arsenal still inside of our centure Ed a
  • 00:43:27
    time we've got linting so most of us are
  • 00:43:29
    probably already familiar with or
  • 00:43:31
    already using um es lint uh an extension
  • 00:43:34
    to this is called um eslint plug-in jsx
  • 00:43:38
    alley have a mouthful um and it runs a
  • 00:43:41
    static analysis of your jsx um for
  • 00:43:43
    accessibility issues in react and these
  • 00:43:45
    will appear as errors and warnings are
  • 00:43:48
    just alongside all of the other ESL
  • 00:43:50
    warnings it comes built in to create
  • 00:43:52
    react app by default and it's got over
  • 00:43:54
    11 million weekly downloads and you also
  • 00:43:57
    has an equivalent plugin there's
  • 00:43:59
    probably also equivalent plugins for
  • 00:44:00
    angular and all of the other
  • 00:44:03
    Frameworks so these look for around 40
  • 00:44:06
    different issues and include common
  • 00:44:07
    mistakes like images without Al
  • 00:44:10
    attributes uh links without accessible
  • 00:44:12
    uh content inside them Mouse events
  • 00:44:15
    missing the corresponding key
  • 00:44:17
    events so this tool can help us identify
  • 00:44:20
    any accessibility issues inside of our
  • 00:44:22
    template but it's not able to test any
  • 00:44:24
    of the rendered HTML output so this is
  • 00:44:27
    where an accessibility testing Library
  • 00:44:29
    uh like ax core from DQ Labs comes in
  • 00:44:32
    this is available as a wrapper for both
  • 00:44:34
    react or view uh and accessibility
  • 00:44:36
    issues are shown in your console and
  • 00:44:38
    given an importance rating to help you
  • 00:44:40
    triage the issues that it
  • 00:44:42
    finds earlier I mentioned an
  • 00:44:45
    accessibility tree uh so this is a lot
  • 00:44:47
    like the document object model or Dom
  • 00:44:49
    tree that you're probably already
  • 00:44:50
    familiar with and browsers create the
  • 00:44:53
    accessibility tree based off of the Dom
  • 00:44:55
    tree and it's used used by accessibility
  • 00:44:58
    apis um for assist of Technologies like
  • 00:45:00
    screen readers to
  • 00:45:02
    consume and you can inspect the
  • 00:45:04
    accessibility Tree in your browser Dev
  • 00:45:06
    tools um I know you can do this in
  • 00:45:08
    Chrome and in Firefox I'm not 100% sure
  • 00:45:10
    about other browsers because I don't
  • 00:45:12
    really use them um report back if you
  • 00:45:14
    know that they're any other ones uh and
  • 00:45:17
    so in this example we're expecting a
  • 00:45:19
    button element um so we can see the name
  • 00:45:22
    and the role wi passed through and that
  • 00:45:24
    it's focusable um if you were looking at
  • 00:45:26
    a div you probably see nothing's been uh
  • 00:45:29
    sent through and this tool can be really
  • 00:45:31
    useful when you're developing um complex
  • 00:45:34
    interactive components and you want to
  • 00:45:35
    see visually sort of what's Happening
  • 00:45:37
    under the
  • 00:45:38
    hood jumping outside of our immediate
  • 00:45:41
    Dev environments now um there will be
  • 00:45:43
    times when you want to assess the
  • 00:45:44
    accessibility of a full page or a site
  • 00:45:47
    or everything together and there's heaps
  • 00:45:49
    of tools for this um but two popular
  • 00:45:51
    options are wave and Google
  • 00:45:54
    Lighthouse wave is a free browser
  • 00:45:56
    exension developed by the folks at webam
  • 00:45:59
    uh it can generate reports and it can
  • 00:46:01
    also add visual markers over your site
  • 00:46:03
    to indicate where it's found relevant
  • 00:46:05
    information and you can just click on
  • 00:46:07
    the overlaid um controls for more
  • 00:46:11
    info Google liouse is a suite of
  • 00:46:14
    auditing tools built into Chrome Dev
  • 00:46:15
    tools uh the lighthouse accessibility
  • 00:46:18
    audit gives a score out of 100 which is
  • 00:46:21
    a weighted average based on a user
  • 00:46:23
    impact uh
  • 00:46:25
    assessments and on the the topic of
  • 00:46:27
    Lighthouse I just wanted to um share
  • 00:46:29
    with you a blog post it's a few years
  • 00:46:31
    old now where a developer named Manuel
  • 00:46:35
    matovich I'm sorry I probably butchered
  • 00:46:37
    that uh aimed to build the most
  • 00:46:39
    inaccessible site possible uh while
  • 00:46:42
    achieving a perfect Lighthouse score and
  • 00:46:45
    I'll link this uh blog in my resources
  • 00:46:47
    as well but the gist is that he was able
  • 00:46:50
    to remove access to the content for
  • 00:46:52
    Mouse users keyboard users cited and
  • 00:46:55
    non-sighted basically everyone while
  • 00:46:57
    still getting a 100% score with a
  • 00:47:00
    visually blank page you couldn't even
  • 00:47:02
    read the HTML by inspecting
  • 00:47:04
    element now the point of his post was
  • 00:47:07
    not that automated tools suck it was
  • 00:47:10
    just that automated tests are just
  • 00:47:12
    automated testing are just the first
  • 00:47:14
    step it shortens the feedback loop by
  • 00:47:17
    allowing us to spot issues during
  • 00:47:18
    development but it can only catch 20 to
  • 00:47:21
    30% of accessibility
  • 00:47:23
    violations that's where manual testing
  • 00:47:25
    comes in there are
  • 00:47:27
    there are two main tools we use for
  • 00:47:28
    manual testing the first is one we all
  • 00:47:31
    already have it doesn't require any
  • 00:47:33
    special
  • 00:47:34
    skills and that's your keyboard all you
  • 00:47:37
    need to do is use a website without
  • 00:47:39
    using the mouse so what are we looking
  • 00:47:41
    for we want to see where our keyboard
  • 00:47:43
    focus is at all times we want to make
  • 00:47:46
    sure that the tab order makes sense
  • 00:47:48
    you're not jumping all over this place
  • 00:47:51
    uh we want to check that all the
  • 00:47:52
    interactive components can be accessed
  • 00:47:54
    um for example date Pickers are fairly
  • 00:47:57
    notorious for um having trouble with
  • 00:47:59
    keyboards um and we definitely make sure
  • 00:48:01
    that everything uh that we can do with a
  • 00:48:03
    mouse we can do with a
  • 00:48:05
    keyboard so after we tested with the
  • 00:48:07
    keyboard it is great to run through with
  • 00:48:09
    a screen reader particularly When
  • 00:48:11
    developing interactive components that
  • 00:48:13
    have different states that need to be
  • 00:48:14
    announced like whether something's
  • 00:48:16
    expanded or collapsed uh and there's
  • 00:48:18
    three sort of main uh main players in
  • 00:48:21
    the screen reader World Jaws is the most
  • 00:48:24
    popular for a person's primary screen
  • 00:48:26
    reader this is available to purchase
  • 00:48:28
    outright or as a subscription for
  • 00:48:30
    Windows it's pretty expensive as an
  • 00:48:33
    option so you're probably not likely to
  • 00:48:35
    test with this yourself unless your work
  • 00:48:36
    is paying for it uh nv8 is a free open-
  • 00:48:40
    source screen reader um it was developed
  • 00:48:42
    by two blind Australians um and it also
  • 00:48:45
    runs on Windows
  • 00:48:47
    machines if you don't want to download
  • 00:48:49
    and install anything um both Apple and
  • 00:48:52
    Windows both have built-in options
  • 00:48:53
    available voice over is built into Mac
  • 00:48:57
    devices and narat is built into the
  • 00:48:59
    Windows operating system neither of
  • 00:49:02
    these are heavily used as a primary
  • 00:49:04
    screen reader but uh so 6.5% for voice
  • 00:49:08
    over and I didn't put it on the slide
  • 00:49:10
    because it's so small Point 5% for
  • 00:49:14
    narrator um but the those numbers do go
  • 00:49:16
    up when you look at the occasional usage
  • 00:49:18
    versus the primary screen read usage um
  • 00:49:21
    so I would say those two options are
  • 00:49:23
    still better than not testing at
  • 00:49:25
    all it can be a little daunting at first
  • 00:49:28
    um while you're getting hang of the
  • 00:49:29
    controls because I don't think they're
  • 00:49:31
    particularly um intuitive um so I do
  • 00:49:34
    recommend just like having a beginner's
  • 00:49:36
    guide up while you're using it and I'll
  • 00:49:39
    link to some of those as well in the
  • 00:49:41
    resources and given over half of the web
  • 00:49:44
    traffic um now comes from mobile phones
  • 00:49:46
    you might want to like to test on a
  • 00:49:48
    mobile device as well voiceover is what
  • 00:49:51
    you'll use on iOS uh and on Androids
  • 00:49:54
    you'll use uh TalkBack so both of these
  • 00:49:56
    are buil into the operating system so
  • 00:49:58
    you don't need to download or install
  • 00:49:59
    anything and I'll add some resources for
  • 00:50:01
    those as well unlike desktop apple is
  • 00:50:04
    the clear winner of uh market share on
  • 00:50:07
    mobile with only 29% of users using
  • 00:50:09
    Android over iOS and all these stats are
  • 00:50:13
    taken from the web aim screen reader
  • 00:50:15
    survey um released in 2021 which I'll
  • 00:50:17
    also add um but the latest survey is
  • 00:50:20
    actually coming out in a few weeks and
  • 00:50:21
    it's got heaps of different stats which
  • 00:50:23
    are really interesting
  • 00:50:26
    uh so when we were testing with a screen
  • 00:50:28
    reader we want to be testing like um
  • 00:50:30
    things like are all the buttons being
  • 00:50:32
    announced correctly or are they just
  • 00:50:33
    saying button um does the link text make
  • 00:50:37
    sense out of context or you hearing a
  • 00:50:39
    lot of a read more learn more and you
  • 00:50:41
    don't know wouldn't know what they were
  • 00:50:43
    about form labels being announced um and
  • 00:50:46
    again those interactive component is
  • 00:50:48
    something collapsed or expanded and
  • 00:50:49
    things like
  • 00:50:51
    that so that kind of wraps us up um so
  • 00:50:54
    just to reiterate and summarize on these
  • 00:50:56
    things that developers can do to make
  • 00:50:58
    our apps more accessible uh so making
  • 00:51:01
    the most of HTML and its built-in
  • 00:51:03
    functionality linking our form labels
  • 00:51:06
    with inputs updating page titles when we
  • 00:51:08
    were doing routing managing the user's
  • 00:51:11
    keyboard Focus uh and using the
  • 00:51:13
    available tools for our
  • 00:51:16
    testing and before we all head off to
  • 00:51:18
    lunch I just want to leave you with a
  • 00:51:20
    final
  • 00:51:22
    thought the web does not just connect
  • 00:51:24
    machines it connects people that's who
  • 00:51:27
    we're creating things for right people
  • 00:51:29
    humans are a really diverse Bunch with
  • 00:51:31
    diverse needs and not everyone accesses
  • 00:51:34
    the web in the same way and when we use
  • 00:51:37
    the techniques we've covered today
  • 00:51:39
    you're not just writing code you're
  • 00:51:40
    making the web a better
  • 00:51:42
    place thank you for having
  • 00:51:45
    [Applause]
  • 00:51:49
    me I don't want to keep anyone from
  • 00:51:51
    lunch uh so if anyone has any questions
  • 00:51:54
    feel free to reach out to me on all of
  • 00:51:56
    these socials or just one of them is
  • 00:51:58
    fine um or just um come talk to me after
  • 00:52:02
    I'll be around until 3:30 before I have
  • 00:52:05
    to catch a plane so happy to have a chat
  • 00:52:06
    with anyone who wants to talk more about
  • 00:52:08
    this or have a question
  • 00:52:11
    [Music]
タグ
  • accessibility
  • single page applications
  • JavaScript frameworks
  • WCAG
  • HTML
  • focus management
  • form accessibility
  • testing tools
  • semantic markup
  • web design