Next month I will continue the tradition of flying over to Austin, TX, USA to attend the annual AccessU conference and teach some classes. Organized by Knowbility, the conference is a gathering of brilliant minds around accessibility and is an excellent opportunity to broaden your accessibility knowledge. Here’s an overview of my four classes:

  • Responsive and Accessible Images (March 17, 2017 – 2:15pm–3:45pm)
    Images are an important part of the web. This course will give an overview of the considerations for accessible images and their alternative texts, but also take a look from a content strategist perspective on how to present pictures in a responsive context. You will learn how to write good alt text, when longer descriptions are necessary, using resolution-independent images, and how to use different images in different responsive contexts for art direction.
  • Advanced Accessibility: Deep Dive for Developers (March 17, 2017 – 4pm–5:30pm)
    This session gives a general overview of good development practices that ensure a more accessible web product. It includes ARIA, styling, and advice for making your website more semantic and thus more accessible to everyone.
  • Use ARIA Responsibly (March 18, 2017 – 8:30am–10:00am)
    How to build web components, websites, and web applications in a way that leverages the capabilities of HTML5. Add ARIA on top to enhance the user experience. You’ll learn where to find information on how to implement ARIA correctly, and shows you a practical example.
  • Simplify Your Development Life with Tools, Tests, and Procedures (March 18, 2017 – 10:15am–11:45am)
    A condensed overview on how developers can simplify their life by making sure that procedures and tests are in place to ensure accessibility in every step.

Tickets for AccessU are still available.

Also, Knowbility is organizing the Inaugural Knowbility Accessibility
Leadership Symposium on May 15th and 16th: The opportunity for senior management to collaborate, confer and learn about accessibility challenges in the enterprise and how to address them, leading to a more diverse customer base.

After AccessU, I’ll attend the W3C Education and Outreach Working Group’s Face to Face Meeting on May 19 and 20.

  • Personal debugging workflow
  • Don’t Write Bugs!
  • Although…
  • the opposite is true
  • the artifact of writing software is fixing bugs
  • gives you experience
  • no silver bullet to debugging
  • you need to pick and chose the right tools
  • debugging helps you to identify issues earlier
  • Disclaimer 1: Frameworks?
    • Don’t have a project that required frameworks.
    • Tools I use are not for frameworks
    • For react: It brings it own debugging tool, because it has to as it is so abstract.
  • Disclaimer 2: I rarely do x-browser testing
    • Current work is not requiring it, mostly doing JavaScript
  • The art of debugging (says wikipedia)
  • The parts to debugging
    1. Replicate
      • Hardest and most important part
      • Bug report: Saving doesn’t work.
      • I know saving works.
      • But it doesn’t work for them.
      • Wontfix is no solution.
      • Litmus-Test to see if it happens at the URL that the user is using.
      • Likely: Series of event happens to the bug
      • Debugging is the end of the process, it should have been caught in tests, right?!
      • Caching and browser add-ons mess with pages
    2. Isolate
      • Pair down to the simplest form where the bug occurs
    3. Eliminate
      • That makes fixing the bug much easier
  • But what is if you have a Heisenburg bug? (A bug that changes its shape while you’re debugging.)
  • Clean the environment as much as possible
  • State
    • All debugging comes out of state.
    • Two types: passive state
      • What happens?
      • Literally looking how the canvas was built
      • Memory history.
    • Interactive state
      • Fixing in the browser to not lose context
      • no back and forth to the editor and back
    • The stack
  • Two methods:
    • Inside out
      • When something changes and you have no idea where in the stack is the error introduced.
    • Outside in
      • You know where the bug is and you go in and edit the file.
  • You can import your local source in the Chrome devtools debugger and link it to the running files
  • Timeline mode is also useful to find performance bugs
  • DOM breakpoints allow you to stop the script when an element changes and shows the code snippet
  • Debug memory leaks with profiles. The memory should be on the level where it started. Snapshot help
  • Red background in profiles: Garbage collection didn’t work out right.
  • There is no silver bullet!

  • Lots of old techniques out there have been outdated.
  • Layout methods have not.
  • Still using the same techniques as we did years ago.
  • Increasingly we’re using frameworks.
  • Add markup.
  • CSS processors.
  • Hopes for layout:
    • Flexbox
    • CSS Grid Layout
    • Box alignment module
  • Give us source oder separation from visual layout
  • precise alignment control
  • relationships to each other
  • Remember Faux Columns? (2004)
  • people jumped at display:table; give us a relationship between columns
  • Separation of content and markup
  • Separation of source and display
  • A bit of a failed promise
  • Need compromises, usually
  • Flexbox and Grid Layout helps to display items in every order
  • Default positioning
  • grid-auto-flow helps to fill gaps maisonette.js style
  • Kind of scary, especially if you think about accessibility.
    • Got a lot to learn
    • Good = Creating the best source with the best markup and then displaying it best for the breakpoint
    • Bad = So, I don’t need to care about the source order
    • Terrible = Flattening out the source order and do everything using CSS grid and flexbox
  • Relationship of the items but independent from source order
  • Control of alignment
  • Box alignment module level 3
    • flexbox alignment to use for other specs
    • VERTICALLY CENTER ALL THE THINGS!
    • Distributed alignment
      • justify-content
      • align-items
        • stretch
        • center
      • justify-self
      • align-self
    • In CSS grid layout
      • Chrome canary
      • align-items center in a css grid with repeated columns
      • instead of stretch
  • Responsive by default
    • Flexbox:
    • CSS Grid:
      • fr (fraction) unit – similar to flex grow
        • grid-template-columns: 1fr, 1fr, 1fr -> same width
        • grid-template-columns: 600px, 1fr, 1fr -> remaining space is shared between column 2 & 3
      • grid-template-areas -> ASCI Art building of layouts
  • But what about old browsers?! I can’t use that stuff!
    • We must to cater for the web of today, but we need to look forward and use progressive enhancement.
    • No layout is not an option.
    • Need to think about feature support differently in a world of evergreen browsers.
    • Business case: How long will the website that you build right now be active, the site will be updated when users upgrade.
    • CSS Grid Layout
      • Early implementation in IE10,11 & edge
      • Current spec in Chrome, Opera (experimental flag)
      • Prefixed in Webkit Nightlies
      • Partial in Firefox Nightly
      • In near future
      • High priority on edge
    • This is not all or nothing. You can begin with small UI elements, use the modern methods for finessing
    • Flexbox in the real world: Zoe M. Gillenwater Enhancing Responsiveness With Flexbox
    • Check stats and compare feature support, for example that is supported by gaug.es
    • Separate mobile and desktop stats – mobile might be more advanced
    • Use such tools for prototyping – you learn how they work, and you immediately can work with it while it is developed
    • You can give feedback to the Working group and it has an effect and they get implemented.
    • It is too late to comment when the things are out in browsers. If you want to be involved, do it now.
    • gridbyexample.com
    • Slides & more information: https://rachelandrew.co.uk/presentations/css-grid

  • You can generate audio using JavaScript
  • Tiny new language
    • small vocabulary
    • few grammar rules
    • couple of ideoms
  • AudioContext
    • like canvas
    • toolbox
    • instance factory
  • Nodes Taxonomy
    • Generation
    • Manipulation
    • Analysis
  • Audio Context as audio graph
  • Modular routing
  • Sound modulation
    • connect() helps you to modulate from one node to another
  • Gain nodes
  • Don’t keep nodes
  • stop and disconnect sound sources
  • load binary data
  • decode into a buffer
  • create buffer source and use it
  • you can even bend the pitch of the audio live
  • place sounds in 2D space – StereoPanner
    • Place to left change pan attribute to -1, to right to +1
  • For 3D space, for example in Games, use Panner
    • update position for accurate placement
    • tries to be realistically physical, so the unit is meters
  • BiquadFilter
    • Let certain frequencies pass
  • Analyser for Visuals
    • Real time frequency and time-domain information
  • Getting creative
    • Real time input + processing
    • Get user media + echoing
  • Web audio is minimal and powerful
    • many built-in nodes
    • one graph, simple connect rules
    • sound generation, processing and analysis
    • great for games, VR and interactive applications
    • it’s also fun!
  • Web audio meetups in London & Berlin
  • Slides: github.com/sole/howa

  • Lets compare tooling to plumbing
  • new type of fitting: Sharkbite
    • Lego for plumbing
    • snaps together instantly
    • can connect any material to copper
    • can be redone
    • less prone to leaks
    • more expensive
    • less error prone
    • plumbers: too expensive, too new
    • changes the industry competely.
  • Some people write off tooling as over-engeneering, others see the benefits
  • Fine line between tooling for tooling’s sake and tooling to get work done
  • Let’s be smart about the tools that we’re using
    • Investments need to pay beck
  • Overwhelmed? Crying? 😭
  • This talk: 😭-> 😃
  • Build tools:
    • biggest barrier to entry
    • a lot
    • what are they for
    • compiling + converting styles
    • concatenation
    • test running
    • deployment
    • anything, really
    • two big: grunt, gulp
    • npm as a built system by using the CLI commands directly using scripts in the package.js, takes bash
      • But probably best used with simple sites
      • hard to maintain
    • Webpack
      • javascript modules focused – gulp meets browserfy
      • bit of a hard to learn api
      • react community likes it
    • What should I use?
      • Pick one. Whatever is best for you.
      • Personally like gulp
        • built speed
        • packages available
        • easy to understand and author
        • overall industry acceptance
        • 47% use gulp, 20% don’t use anything
      • Sass brought people to the built train
  • Performance
    • Critical: First paint is important
    • Purify: Removes unused CSS
      • Looks at JS and CSS and finds unused CSS
      • Much smaller CSS files
    • ImageMin: common interface to 17 different image compression libraries
      • Recommendation: MOZJPEG
    • Uglify.js: Minifies, compresses and mangles code
  • Dependency + Module Management
    • We’re seeing a huge shift on how we manage frontend dependencies
    • Problem: Many scripts, duplicated, different versions of the same file
    • The solution: Modules for javascript
    • How does it work
      1. Install your libraries, ex. npm/bower install jquery
      2. Write your code, ex. var$ = require(‘jquery’); or in IE6: import $ from jquery
      3. Compile into a single or multiple bundles
        • Browsify – simple, quickest setup
        • WebPack – handles css
        • JSPM – client side, close to JS spec
      4. Stop?! What about Gulp/Grunt?
        • They are task runners, one of the tasks will be “bundle javascript”, they can call those bundlers.
    • Small modules that do one thing, and one thing well
    • Only need ajax, npm install fetch
    • Pick and chose from lodash
      • Is coded in a way that you can access all methods individually, exports only that module to use
    • NPM or Bower?
      • Libraries, similar
      • NPM for everything!
      • Ecosystems coming soon to NPM, helps categorize the modules
  • The Future
    • JS + CSS evolve rapidly
    • Don’t need to wait with future code today
    • Wasn’t possible before
    • JavaScipt
      • ES6/7/Next
      • Arrow functions
      • let and const for variable declarations
      • template strings
      • many more
      • Babel
        • Allows you to write IE6 code but will then compile it to code that will work today.
        • gulp-babel
        • What about new language features?
          • polyfillable require babel/polyfill
    • CSS4
      • Everyone 😍 SASS, comes to browser
        • Nesting
        • Scoping
        • Variables
      • CSSnext allows to write in CSS4 and compiles to CSS3
      • part of postCSS ecosystem
      • quantityQueries helps to work with those, also a postCSS plugin
  • Workflow treats
    • Browsersync – like live reload but actually works
      • Instant reload
      • Includes server with cert for easy local HTTPS
      • Proxies existing applications/servers: Wordpess, ruby, python
      • Exposes server via local IP, can test on multiple devices
      • Syncs clicks, submits, scrolls
      • MAGIC
    • Sourcemaps
      • Code goes through several transforms before it is in the browser
      • If there is an error that needs to be traced back
      • Sourcemaps is standardized
      • Can be used with a lot of plugins
  • Tooling is extremely important
  • Everyone should have  built process
  • Sky is the limit
  • Better code