Typing Towards An Accessible Web

Tessa Kelly

NoRedInk

github: @tesk9

twitter: @t_kelly9

Follow along:

slides.com/tessak/   
typing-web/live

Doing the right thing

Do you Know that your application works for

 

  • Mouse users?
  • Keyboard users?
  • Screenreader users?
  • Visually-impaired users?
  • Users who need extra time to process material?
  • Users with epileptic photosensitivity?
  • All of the above?

Why aren't OUr applications                           ?

Accessibile

How do we know our code works?

P

O

U

R

erceivable

perable

nderstandable

Obust

How do we know our code works?

  • Unit tests
  • Integration tests
  • Visual regression tests
  • Static analysis tools
  • We run the code & check it ourselves
  • We hire QA professionals to check it
  • We watch metrics & look into elevated error rates aggressively

For               do we know our code works?

WHOM

strategies for deploying working code

Let's try to apply our

to benefit all our potential users

Strategies for deploying working code

  • Unit tests
  • Integration tests
  • Visual regression tests
  • Static analysis tools
  • We run the code & check it ourselves
  • We hire QA professionals to check it
  • We watch metrics & look into elevated error rates aggressively

What do we do with support requests?

Strategies for deploying working code

  • Unit tests
  • Integration tests
  • Visual regression tests

 

  • Static analysis tools
  • We run the code & check it ourselves
  • We hire QA professionals to check it
  • We watch metrics & look into elevated error rates aggressively

Strategies for deploying working code

  • Unit tests
  • Integration tests
  • Visual regression tests

 

  • Static analysis tools
  • We run the code & check it ourselves
  • We hire QA professionals to check it
  • We watch metrics & look into elevated error rates aggressively

Follow along:

slides.com/tessak/typing-web/live

Integration tests

it "can be toggled open and closed" do
  find("#log-in").click
  expect(page).
    to have_selector(".login-modal-form")

  find("#log-in").click
  expect(page).
    not_to have_selector(".login-modal-form")
end
it 'can be toggled open and closed' do
  click_on "Log In"
  expect(page).
    to have_content "Email or username"
  expect(page).
    to have_content "Password"

  click_on "Log In"
  expect(page).
    not_to have_content "Email or username"
  expect(page).
    not_to have_content "Password"
end

Integration tests

it 'can be toggled open and closed' do
  click_on "Log In"
  expect(page).
    to have_content "Email or username"
  expect(page).
    to have_content "Password"

  click_on "Log In"
  expect(page).
    not_to have_content "Email or username"
  expect(page).
    not_to have_content "Password"
end

Failure/Error: click_on "Log In"

Capybara::ElementNotFound:
 Unable to find link or button "Log In"

Integration test benefits

  • Capybara's API encourages semantic HTML
  • ...which leads to nicer-to-read tests
  • ...and a more robust application
  • ...and improves accessibility!

Strategies for deploying working code

  • Unit tests
  • Integration tests
  • Visual regression tests

 

  • Static analysis tools
  • We run the code & check it ourselves
  • We hire QA professionals to check it
  • We watch metrics & look into elevated error rates aggressively

Elm

A delightful language for reliable webapps

  • No Runtime Exceptions
  • Great Performance
  • Enforced Semantic Versioning
  • Small Assets
  • JavaScript Interop
  • Makes it harder to write invalid HTML

Easier-to-write Valid Html

import Html exposing (..)


view =
    div [] [ text "Hello, ReactiveConf!"

Naming Error
Line 7, Column 14
I cannot find a `txet` variable:

7| div [] [ txet "Hello, ReactiveConf!" ]
                ^^^^
These names seem close though:

    text
    cite
    del
    dt

import Html exposing (..)


view =
    div [] [ txet "Hello, ReactiveConf!" ]

Parse Error
Line 8, Column 1
Something went wrong while parsing a 
list in view's definition.

7| div [] [ text "Hello, ReactiveConf!"
8|
   ^
I was expecting:

  - an argument, like `name` or `total`
  - the end of that list. Maybe you 
    forgot some code? Or maybe the 
    body of `view` needs to be indented?

InteractiVe Elm

import Html exposing (Html, div, text)
import Html.Events exposing (onClick)


view exclamations =
    div 
        [ onClick (exclamations ++ "!") 
        ]
        [ text 
            ("Hello, ReactiveConf!" 
                 ++ exclamations) 
        ]

Oooooooops!

🤦🏻‍♀️

The clickable div strikes again!

🤔

How can we avoid this mistake?

💡

Inaccessible code

shouldn't compile

tesk9/accessible-html

➜  elm install tesk9/accessible-html

import Html exposing (Html, text, div)

viewHtml : Html msg
viewHtml =
    div [] [ text "Hello again!!" ]

 Elm/Html

import Accessibility 
    exposing (Html, text, div)

viewAccessibleHtml : Html msg
viewAccessibleHtml =
    div [] [ text "Hello again!!" ]

 tesk9/accessible-html

using

elm/html

import Browser
import Html exposing (..)
import Html.Events exposing (onClick)

view exclamations =
    div 
        [ onClick (exclamations ++ "!") 
        ]
        [ text 
            ("Hello, ReactiveConf!" 
                 ++ exclamations) 
        ]

import Accessibility as Html exposing (..)

                      

tesk9/accessible-html

Type Mismatch
Line 17, Column 9
The 1st argument to `div` is not what I expect:

17|     div [ onClick () ] [ text ("Hello, ReactiveCon"...
            ^^^^^^^^^^^^^^
This argument is a list of type:

    List (Html.Attribute ())

But `div` needs the 1st argument to be:

    List (Html.Attribute Never)

Guaranteed

Divs                    event listeners

without

(except for when you're reeealllyy sure you want them)

A curated selection of html elements

  • <html>
  • <link>
  • <meta>
  • <style>
  • <title>
  • <body>

Roots & meta elements

  • <header>
  • <nav>
  • <main>,<aside>,<section>,<article>
  • <h1>,<h2>,<h3><h4><h5><h6>
  • <footer>
  • <address>

Page structure & layout

  • <blockquote>,<cite>
  • <p>,<pre>,<code>
  • <div>,<span>
  • <dd>,<dl>,<dt>
  • <figure>,<figcaption>
  • <hr>
  • <ul>,<ol>,<li>

Text elements and such

  • <img>,<map><area>
  • <audio>,<video>,<track>
  • <picture>,<source>
  • <embed>,<iframe>
  • <object>,<param>
  • <canvas>,<noscript><script>

 

Media and embedded content

  • <table>
  • <tbody>,<tfoot>
  • <th>,<tr>,<td>
  • <col>,<colgroup>
  • <caption>

Tabular information

A curated selection of html elements

  • <form>
  • <input>,<output>
  • <textarea>
  • <button>
  • <select>,<option>,<optgroup><datalist>
  • <progress>
  • <label>
  • <fieldset>,<legend>

Forms

  • <details>,<summary>
  • <dialog>
  • <menu>,<menuitem>

Interactive elements

  • button
  • checkbox
  • color
  • date
  • datetime-local
  • email
  • file
  • hidden
  • image
  • month
  • number
  • password
  • radio
  • range
  • reset
  • search
  • submit
  • tel
  • text
  • time
  • url
  • week

Types of HTML Inputs 

...So when would you actually

want a clickable div?

want

  1. You can improve accessibility on the web
  2. Integration tests can be powerful
  3. Type checking has some neat applications

We still don't know our code works for all users.

Images                     Meaning

without


<img src="assets/pretty-flower-0f4a0e47782fcec1a2a7eb824eedb2b13fb9c52412e298039771c869396f87ab.jpg" />


<img alt="" src="assets/pretty-flower-0f4a0e47782fcec1a2a7eb824eedb2b13fb9c52412e298039771c869396f87ab.jpg" />

import Accessibility exposing (decorativeImg)
import Html.Attributes exposing (src)

decorativeImg [ src "assets/pretty-flower-0f4a0e47782fcec1a2a7eb824eedb2b13fb9c52412e298039771c869396f87ab.jpg" ] 

import Accessibility exposing (img)
import Html.Attributes exposing (src)

img 
    """Piano, broken beyond repair, 
       sitting incongruously on the 
       edge of a driveway
    """ 
    [ src "assets/images/broken-piano.jpg" ]

does our code work for all our users now?

takeaways

  • Use semantic HTML
  • Build tools that protect against accessibility mistakes
  • Make API choices that guide towards accessible results
  • Remember that building accessible code means design work

Tessa Kelly

NoRedInk

twitter: @t_kelly9

github: @tesk9

Thank

 

you

If you're interested in learning more about accessibility best practices, I recommend browsing the WCAG guidelines.

 

 

 

MDN also has friendly resources available.

 

 

I'd love to hear about whatever you build!

Made with Slides.com