CSUN Day 3 Notes

My notes from Day 3 of the International Technology & Persons with Disabilities Conference (CSUN)


Here are my notes for Day 3 (and my last day) at the 2016 CSUN Conference. Please excuse any weird spelling, grammar, meaningless hyperlinks, or formatting errors. Reference to pictures are unavailable within this post as I probably shouldn’t have taken them – but I can’t type as fast as people speak.

Common Testing Mistakes

  • SSB Bart slides will be posted online
  • presentation = slides

7 Things Every Designer Should Know AND The Future of Web Accessibility Research are full.

Teaching Closed Captioning to Students

  • Captioning for Educational Media: http://www.captioningkey.org
  • SPTE, W3C, CEA, EBU specifications rule the captioning world
  • The web is the Wild West; broadcasts captioning is constant

Tweets from @ellenking from 7 Things Every Designer Should Know

  • Avoid “big vast sheets of white” with little indication of where form fields are.
  • Lightest gray on white #ffffff is #767676. Get used to it.
  • Colorsafe.co One color and then all color that are safe contrast wise.
  • Don’t set :focus{outline:0;} in your reset file.
  • Don’t make people hover to find things, especially actionable things.
  • Don’t nest accordion in a menu.

A Publisher’s Dilemma

  • What output is best? What reading method is best?
  • Book Plug: Ensuring Digital Accessibility Through Process and Policy
  • Case study book: biography
  • First vendor said they new accessibility, showed tests where all passed (but tags were not checked)
  • New Vendor: new issues
  • Karen McCall saved the book
  • Book-sized PDFs tend to crash and burn
  • Tagging references is hard; no one agrees on how to use H1
  • Mystery links appear: (had to delete two pages to get them to go away)
  • Tags disappear
  • Adobe Digital Editions is a disaster; worse than Acrobat
  • iBook on iPhone is much better than on the Mac
  • Baseline initiate by George Kerscher (see slides on Slide Share) https://www.slideshare.net/mobile/daisyconsortium/baseline-for-born-accessible-epub-3
  • BISH Quick Start Guide for Accessible Publishing (not short, but has a great appendix, resources) https://www.bisg.org/news/bisg-quick-start-guide-accessible-publishing-moving-inclusion-forward
  • Speaker working on a book on circuit diagrams. ALT text not useful here. Limit to the tools we have can do.
  • Common Look or PAC offer free validators for PDF; audience member finds CL product easier to use

WCAG: New Needs, New Work

  • Released new docs; updated quick guide
  • Working draft for low vision; low vision task force
  • Considering Extensions: mobile; cognitive; low vision: or all in one as a WACG 2.1
  • Extensions approach issues of changing technology
  • WACG Working Group meets on Tuesdays
  • Recognize that WCAG touches many professions and organization: All voices are welcome at the Working Group
  • Need to balance perspective for WCAG; set requirements;
  • WAI Interest Group
  • Task Forces looking into models to approach issues
  • All different technologies are merging into the web with W3C; haptics; broader area guidelines
  • Need for ppl with knowledge of the field (new technologies)
  • Concentrating on web content, but looking at applications; resize there are limitations

#VLshow taping social

  • Paciello doing research on using pitch and tempo for graphs (tempo found to be more effective)
  • Metzessible: YouTube channel on accessible docs to PDF from Word; feels Common Look does the same as Acrobat; uses Acrobat; specializes of UA

Low Vision: Beyond the buss words

  • #lowvisbuzz
  • YouTube video with examples of vision simulations http://www.visionaware.org (?)
  • Seniors just assume loosing vision is part of vision; early intervention is key; ask questions like “Do you have trouble seeing?” Instead of “Do you have low vision?”
  • Profs need to rethink AT: AT not for recording/cheating, but for access

EPUB3 Accessibility

  • Vital Source (?) product demo

Word to PDF

  • Lists can be nested; child lists within parent list; child lists need LBODY tag
  • Content order must match Tag order; will help ensure reading order if document is reflowed
  • TBase (speaker’s company) uses Acrobat and PAC to check docs
  • Audience, Karen McCall: can have more than one H1 in a PDF document

Digital Accessibility Trends

  • Slides online
  • Trends: interactive devices; mobile etc – accessing info through multiple devices
  • Framework as a primary coding approach
  • Responsive web design; gestural input
  • ePub; PDF – SSB Bart (speaker) focuses a lot on this
  • Moving beyond ‘project based accessibility’ to maturity models

Adobe Accessibility Update


  • Adobe Document Cloud services hook into web front end, Acrobat, Reader; mobile apps
  • Ability to sign law documents
  • Adobe.io set of programming UI and kits using what’s available in all of Adobe’e cloud; enterprise software; middle-ware
  • Marketing Cloud: hosting website’s; social media;
  • Adobe Accessibility more than Acrobat

Acrobat Document Cloud

  • High contrast mode
  • Keyboard and screen reader mode improvements
  • to improve for VoiceOver for OS X; reading tables


  • PhoneGap Mobile Accessibility: open source project for developers
  • AEM: content management ; create WCAG 2.0 AA websites; https://docs.adobe.com/content/docs/en/aem/6-1.html
  • Adobe has an internal GitHub; internal open development
  • Beginning work with common UI front end for desktop Adobe products
  • US govt has a component set of Adobe components to create code
  • ADOBE WILL BE ADDING AN UNDO BUTTON TO ACROBAT (no set date for release though)


  • Accessibility/compliance.html
  • Adobe will be posting all CSUN slides on their blog

Building an Accessible Culture: TELUS

  • Make it a practice, give value to make it sustainable
  • Not common: started small
  • MVP tasks: UX, DEV, QA
  • Slowly build up accessibility
  • user-centric design process
  • Agile lean culture; cultivate awareness
  • Made a Top 10 List to tackle first (big impact, relatively simple to do)
  • UX Principles for team: Colour contrast;
  • Intended design not always the reality (dim screen, projector colour off)
  • Challenge how to bring accessibility to the front when it was always an after thought

UX Design at TELUS

  • Darken green, bump up text size and bold text
  • Does it still make sense to refer to print colours when most customers interact with our product online?
  • If using colour to signify something, pair with icon/underline/pattern
  • Icons and images that are not crucial are labelled decorative (including TELUS critters)
  • No critical info in images
  • Uses Helvetica Neue – thin and ultra thin look great in print but not on screen
  • Started to phase out light weights
  • UX team uses Google Draw for wire framing; Sketch with Zeplin plugins
  • SimDaltilism? (App to test colour blindness)


  • aXe plugin from Deque; both developers, QA, and designers can use; works on multiple browsers
  • Totally from the CAN Academy (?)
  • Keyboard functionality was a big problem; guarantees responsive design for touch in addition to mouse/touch
  • Label form fields, hyperlinks, GUI etc consistently has a huge positive impact


  • Define criticality of a11y bugs; rank a11y bugs amongst each other
  • Maintain criticality Wiki to guide QA on what to fix first
  • Exploratory testing: http://guide.agilealliance.org/guide/exploratory.html
  • Pick and choose what to test, then focus
  • Pa11y.org to test change over time for public facing websites
  • Create empathy lab to see how it works
  • TELUS caters to an ageing market
  • teachaccess.org
  • Add a11y into job descriptions
  • Don’t pose accessibility as something new – rather something normal, expected
  • About 6 months to get this going consistent
  • Walk through problems together as a group with expert

Pre-conference Notes


Friday, March 25:


  • Free & Low-Cost AT (Hillcrest AB, 3rd FL)
  • WCAG: New Needs, New Work (Harbour Ballroom F, 2nd FL)
  • Writing Accessibility Tests Using JavaScript & CSS (SSB Bart room)
  • Power Up Your Student’s Research Project (Promenade AB, 3rd FL)



CSUN Day 2 Notes

My notes from Day 2 of the International Technology & Persons with Disabilities Conference (CSUN)

Here are my notes for Day Two at the 2016 CSUN Conference. Please excuse any weird spelling, grammar, or formatting errors. Reference to pictures are unavailable within this post as I probably shouldn’t have taken them… but I can’t type as fast as people speak.

Accessible Maps

  • speaker: @accessibilityoz at gain@accessibility.com.au
  • Inform the user that there is a long description in the ALT text
  • “this is the Goal Coast Train line an dits X miles long”
  • “there’s a slight incline from the house that such and such built, and you turn left..”
  • Long descriptions are visible to everyone, so it can have additional info to the map itself
  • ALT should not have additional info
  • Developers: label pin markers that are useful “South Fitzroy” etc
  • Alternative: provide a list view of maps if you can’t alter the code
  • Keyboard/touch accessibility
  • “Zoom of zoom” can’t move anything but the map
  • Ensure all actions can be completed using mouse, touch keyboard etc
  • Google Maps you get are very keyboard accessible now (maps.google.com)
  • Press tab to see blue outline, keyboard accessible, see labels
  • When you embed Google Maps there are issues, third parties
  • Blue green colour blindness is common
  • Best practice: colours contrast with white or black and use borders, label sections of map (example: wards)
  • Juicy Studio Luminosity Colour Contrast Analyzer (new to me!)
  • Ensure users can increase the size of the map and map content (interactive maps online)
  • pz.tt/CSUN16-map (speaker slides on maps)
  • Google audience member: problem with embedding, can’t tab through everything, update launching in 2 weeks where you can
  • Answer to another audience member’s question: native apps are difficult as you can’t access the code. You can’t go to the code and apply a label. In this case, include a long description.
  • Work around: link off to Google Maps if your map is not accessible

Diversity Within Accessibility: Workforce and Product Design

  • Speaker: Sassy Atwater, work in fashion and advocacy for PwD; Also works in acoustic physics
  • Not a lot of companies that cater to where I like to shop; Focus of talk on UX
  • We cater to one mindset – not diversity (ex: Stevie Wonder and Braille card at Grammies)
  • We need to be the catalyst; we need to be both the dream team and the orange (Whole foods packaged oranges: accessible packaging but wasteful packaging when it naturally has a peel)
  • Universal design allows customization; can solve diversity issues for employers
  • UX is like underwear: we all use it; all interact with it; we all have that experience
  • Does someone with CP know where openings are and how to get it one; does a blind person know what colour/pattern it is [when shopping online alone]
  • How do races; minorities; people come into that environment; how does minority experience affect the product you’re development
  • Infographic: most people 50+ do not how to use built-in tools; we are designing for a group that cannot utilize the tools we’ve designed for;
  • Universal design interacts with ‘common sense design’

Accessibility for UX Designers

  • Point of talk: UX Designers need to take on the extra work that accessibility brings; Accessible UX design 101
  • Note: the slides were really hard to read even after upping the contrast; body font does not work for distant reading – open, round, thin stroke. Heavy weight worked, light not. Familiar font – look up and note.

The Digital Accessibility Maturity Model

Making Non-English Content More Accessible

  • Speaker: Elizabeth J Pyatt, Penn State, AccessAbility
  • Talk changed topic or title? Not about images for non-english
  • Language Codes: ISO-639
  • Also, 3 letter codes: ISO-639-3
  • Region codes: en-US vs. en-GB (work for spell checker, not doesn’t seem to affect accent)
  • WikipediaTend to use 2 letter code; three letter when available
  • Not great support for less popular languages (ex: Cherokee)
  • Language tags in Word/PPT works well: highlight word Tools > Language > select language used for word)
  • PDF: tags do not carry over from Word/PPT (PDF only accepts one language)
  • JAWS plugin for languages
  • Voiceover: download different voices, but sounds weird is switching back and forth between accents in a document
  • Unicode: A B C D E F in Unicode – screenreader will read the letter (Wingdings)
  • Do screen readers read symbols: (see pic)
  • Need JAWS symbols file: eloq.sbl in settings (see Freedom Scientific) (see pic for URLS)
  • Install script to get JAWS to read unicode correctly
  • VoiceOver: Speech Tab > Pronunciation > modify for what it should say
  • Developing websitess for non-English text: https://t.co/5NeolcUOXl
  • Foreign Language Accessibility resourc: https://t.co/pDCNbNRIcd


  • ARIA is for emergency use only
  • Pretend its an image and give a label
  • Hide an embedded icon
  • If a course, recommend beefing up symbol and font repository
  • Accents present a legibility challenge
  • Speaker feels that sans serif fonts are more legible when it comes to accents over letters
  • Andika is designed for different languages (Others: Charis SIL; Georgia)
  • Non-Western characters: mad need to increase font sizes
  • Really likes Text/Expander/Beevy: simplifies keyboard sequence; customize; robust; can do whole words

Is it a link or a button: ultimate showdown

Wearable Assistive Device Development Tool

  • University project presentation (Japan)
  • AeonKit: development kit without the need for coding language
  • Kit focuses on hardware
  • See handout for summary of session
  • Works on Andrino and Raspberry Pi; mac and pc; Code on GitHub

Accessible Publications with Adobe Digital Publishing Solution

  • Speaker: Matt May, Sr. Program Manager, Accessibility, Adobe
  • Adobe does not sell product in title anymore; focus on Adobe Experience Manager Mobile (AEM)
  • Having a town hall meeting tomorrow
  • AEM possibly best program for accessibility (re-enforces this is not a sales pitch; no commission)
  • AEM used to be known as CQ; digital management
  • Adobe is hiring product dev and managers right now
  • AEM and other products in the Marketing Cloud
  • AEM publishes content as apps; Individual articles, bind as an edition; manages subscriptions and levels of control; content management

Accessible SVG Charts using ARIA

  • Highcharts demo, documentation, downloads: www.highcharts.com
  • Interactive charts for web projects
  • Free for non-commercial use; open
  • JavaScript
  • Works in all mobile and desktop
  • Can generate tables from SVG content study found that tables were preferred
  • complex box plot SVG
  • Too many headings = cognitive overload
  • Chart types themselves need a description (what is a box plot)
  • Data Table usability: if marked up well, they offer more flexibility
  • Best practice: offer both a table and an SVG chart for user preference

Digital Accessibility Training Solutions

  • Review training engagement
  • 5 phase approach: develop plan; dev. design; storyboard; training materials; deliver training; long term strategy
  • Training aimed at policy makers; internal team; could work for outside audience, techy or not
  • Summary of each phase in slides (posted later)
  • SSB Bart does InDesign and Acrobat training
  • Felt slides weren’t very effective; found video training more engaging
  • Videos should last 3-5 minutes; anything longer looses attention
  • Hands-on exercises (Codepen) work well for in-person training to engage the team
  • Codepen is not a fully accessible product
  • SSB Bart uses Moodle for their backend LMS

Between Session Discussion with Microsoft employee:

  • Microsoft Disability Answer Desk: free to PwD, consumer channel
  • Answer Desk: aka.ms/accessibilitysupport
  • Very patience; trained in common assistive technology
  • There is also an Enterprise level for IT teams etc.

Pre-Confference Notes


Thursday, March 24:





CSUN Day 1 Notes

My notes from Day 1 of the International Technology & Persons with Disabilities Conference (CSUN)

Here are my notes for Day One of the 2016 CSUN Conference. Please excuse any weird spelling, grammar, or formatting errors. Reference to pictures are unavailable within this post as I probably shouldn’t have taken them… but I can’t type as fast as people speak.

9am (hopped between multiple talks)

  • Equidox offers software that converts pdf docs to html that is claims is better that Common Look or Acrobat
  • NASCIO has published a two part series in accessible procurement
  • Case Study: airlines didn’t change logo, but contrast within the font family

The WordPress Way

  • Talk focus: How to maintain accessibility? What is going on?
  • JavaScript wp.a11y.speak() to generate and announce JS updates in ARIA Live region
  • Release of H1 headings on admin screen; fixes to list tables, focus, focus styles
  • Release of Twenty Sixteen
  • Review of colour contrast; review of content-bearing title attributes
  • Twenty-Sixteen is very heavily audited – very accessible
  • Installing other plugins, widgets etc will screw things up
  • Need of tighter style guidelines for WP admin (50 shades of grey being used – need to scale down to 10)
  • Big areas: include contrast and backend of admin
  • Problem: list tables structure used for posts (put your HTML in a post, but it maybe in a table)
  • Media management UI code is a mess (talk of complete rewrite)
  • Backwards compatibly is a problem – 25% of websites on the internet are WP
  • Updates break websites
  • You’re affecting a lot of sites and people; those people will be very unhappy; have to be careful
  • WP has a statement that it strives not to break backward compatibly
  • adding a label is simple, but causes a ot of debate as it changes a theme (label where there was none before)
  • Creates ‘technical debt’ with backwards compatibility
  • Every plug-in is on Git Hub (useful for developers changing code) (not premium plug-ins)
  • WordPress does a lot of testing before a release is put out
  • User experience different than developer’s (dev “accessibility is great!” user “my website doesn’t work. Accessibility is a problem.”
  • List Table used for posts and plugins
  • List Table slows down=b changes – huge technical debt
  • List Table is html independent, controlled by the class itself
  • Updating the setting API and WordPress Admin settings is a really complex problem to solve (working on new fields API)
  • Other WP problems:
  • internationalization (change to other language, 80 lang right now)
  • labelling
  • accretion of new options without discarding the old
  • need to keep up with everything
  • colons help with internationalization (no structure is universally translation-able)

New Stuff

  • Calypso: new JS single page app (Joe says its a disaster, requires you to constantly jumping back and forth between old admin and Calypso)
  • REST API (for WP Core; custom JS admins; new challenge; pressure on WP Core to do own single page JS cap – very limiting, not good)


  • Officially committed to meeting WCAG 2 Level AA in future development
  • high expectations for new code = slower development
  • This will take over a decade
  • Mistakes will be made, we will miss things – but we have a great principles
  • WP has guidelines, standards – removes debate whether this is a issue to address
  • high expectations for new code will prevent the issues WP os currently having
  • Some rules for developers


  • harder to find the low-hanging fruit
  • some things that appear to be low hanging are not
  • The REST API opens a whole new set of challenges

@joedolson #csun16
make.wordpress.org/accessibility/ (you’re welcome to join to help out when you can)

Post Talk Discussion

  • We need people to test; write documentation; looking at code; financial support everything is getting more abstract. instead of writing code that gives it an ID etc, you write a function; then wp generates all the code to make that
  • wp makes a change effects everything using that api or nothing at all
  • Audience: internationalization is overlooked by WCAG
  • WP core is about single language sites
  • multi-language is left to plug-ins
  • multi language is hard
  • in principle, solvable – add field to define language (Wp has built in languages that can be linked language codes
  • Not single solution to multi-lingual
  • ARIA in WSIYG is very hard problem to solveWP competitors are far behind in accessibility (SqareSpace etc)
  • Drupal is good
  • Making sites simple is not asking ppl for not inputting an ALT (SquareSpace, format)
  • As long as their is a market, it will continue to be a problem
  • The more complex a UI, the harder it is to use
  • Accessibility adds layers of complexity (captions etc)
  • Progressive interface is part of the solution (prompted to add captions; add image with ALT) but only works if you have an extremely controlled layout (but control is not popular)
  • Almost nothing in WP has been removed; rarely deprecated (if it has a major security flaw, it will be removed)

Accessible Documents

  • everybody being accessible reduces the backlog on web teams
  • user-generated content be accessible
  • real trick: throwing everything and the kitchen sink scares people – success
  • 125 page doc on making accessible Word doc (put out by security? gov?)
  • 7 principles of accessibility (minimum checklist)
  • new refresh of 508 will mandate sans serif font for kiosks
  • Section 508: size for prescription bottles and law docs
  • use WCAG 2 Success Criteria
  • helpful to provide the law that ‘says so’
  • break rule on font size on forms (example DSS Standard of Arial 12)
  • Full justify is the only Level AAA he includes in standard
  • Very important to check text for colour blindness (analyzer tools focus on vision colour contrast, very important to think of colour blindness)
  • some screen readers can tell you font colour, but its a big pain
  • Mark mandatory fields with * instead of colour only (red asterisk, happy medium)
  • *most screen readers stop reading ALT text around 180 characters*
  • Note on presenter’s slides: hyperlinks to WCAG to back up what they’re saying; reference
  • Simple tables: do not merge cells; do not split cels; have only one row in the header
  • The hardest thing about accessibility os philosophical
  • Learn a different way of making things
  • rewording can help make simple tables (see pics)
  • Graphic designers will learn how to make documents that look good, but it will take time to learn how through learning how to think creatively
  • Don’t put a lot in your standards at first to help designers ease into accessibility
  • When you first got InDesign, your docs didn’t look good – it took time
  • Accessible docs will look crappy at first, but with practice they’ll look great once you’ve changed your way of thinking
  • Screen readers can pull up a list of all hyperlinks in doc (importance of meaningful links)
  • “Is a heading a heading if you don’t assign it as a heading?” (Accessible document Philosophy 101)
  • Everyone needs to test for accessibility
  • Can’t always get rid of all the red X’s in Acrobat with forms
  • http://www.dor.ca/gov/disabilityaccessinfo/ (free resources on accessible documents)
  • Bug in Office 2010 that puts all the image tags on the first page
  • http://www.dor.ca.gov/disabilityaccessinfo/digital-access.html
  • Joe Krack (speaker)

Accessible Forms

  • Section 508 and WCAG covers all electronic content
  • 7 Essentials (see iPhone pic)
  • Screen readers need to go in forms mode
  • Once in forms mode, it only sees what is behind the scenes
  • No resources yet on making auditory forms, focus on visual forms
  • Windows Eyes is free fir Word users
  • Translate visual clues into text
  • Tooltip “Street Address” instead of “address”
  • Sub checkboxes ect need to include the heading in the tooltip (and heading, and thorough explanation so it makes sense)
  • Ensure tooltips include all necessary information (because its not reading the other text around it – just the form fields)
  • Include whether its optional (if it is) in the tooltip
  • Any text that is not part of a forms field, it is never read to someone in Forms Field
  • Read only n Acrobat is helpful to convey information that maybe missed in a form (total is of an order)
  • No hard returns in tooltips
  • Note: audience confused by Read Only
  • Auditory forms may not pass Acrobat’s Accessibility check, but will be more accessible – audible AND visual
  • Never rely on one tool for testing (speaker uses Acrobat)

Overheard in hallway (discussing about dating app for seniors?) “Instead of saying “Do you have a disability?” ask “Do you have difficulty with the following…?”

Digital Accessible Best Practices talk rescheduled to Thursday? (waited for speaker, didn’t show)

Designing Accessible Workplace Applications

  • Use waterfall process (see iPhone pic)
  • Pros: integrated a11y early on; well defined.predictable; easy documentation
  • Cons: not flexible; longer timeline; change to scope of accessibility requirements more difficult
  • See iPhone pics for slide pics

Google Docs Accessibility

  • Placing, wrapping image will read between content; in-line will read where it appears
  • Right click to apply alt text or search the menus
  • Accessible tool bars can be accessed using a switch device (mobile and desktop apps)
  • Note: really nice room; good place to go and sit when other talks are un-engaging

Accessible bar graph talk full – presentation slides: http://haltersweb.github.io/Accessibility/barchart.html

Common Look

  • Reading order in Acrobat is not relevant; order of Tags is important
  • Common Look tests against WACG and PDF UA
  • We can send pdfs to sales rep to do a demo on; can do a private demo for one person or a group at the org

Pre-Conference Notes


Wednesday, March 23:





Designers vs. Accessibility

Designers are often resistant to accessible and inclusive design practices. This post explores possible reasons why with a proposed solution through a shift in process.

This is the full version of the article written for the March issue of the IDA-N: Inclusive Design Monthly Newsletter, Vol. 2 Issue 3.

Graphic design combines creativity and functionality with a healthy mix of collaboration, aesthetics and problem solving for both on-screen and on paper. There is an aspect of art in a graphic designer’s work, but I’ve always felt that function is the more prominent feature of graphic design.

Design is, generally, about displaying information in an easily digestible, meaningful way for the widest possible audience. With this view in mind, I’ve found it surprising that designers are so resistant to accessible and inclusive design practices. This was perplexing and frustrating at first, but the more I work with other designers and clients, the more I come to understand two possible reasons why.

Taking away from designers

No one likes being told how to do their job – especially by people who have never done your job! The Accessibility for Ontarians with Disabilities Act (AODA) has brought up an entirely new framework to graphic design. There is confusion about and between legislation, policy, design guidelines, branding, and best practices.

For example, a client requests a poster for an event. The designer creates the poster that is compelling, informative, and legible. Then the client comes back asking whether this is AODA compliant. The designer feels like their skill, style and judgement is being undermined by legislation.

Clients often come to designers demanding 12 pt. font and sans serif font like Arial or Verdana for everything because that’s what example they were given during their accessibility training. Yet, by making all text 12 pt. the design may sacrifice other things such as whitespace and hierarchy, which also apply to accessible design. Although their intention is good, it can create other problems.

It is our jobs as designers to speak to the widest possible audience and we are trained on this. If making text 12 pt. for a project with small dimensions, such as an ad in a newspaper or in the sidebar of a website, is going to make everything squished and unreadable, we need to inform the client. We need to tell the client why we feel this is not the best way to approach the project. Designers need to feel like they have a voice and the power to make good design happen.

It can also be helpful to send other designers or clients a link to the Information and Communication Standard, pointing out that the AODA says nothing about how big a font should be or what type of font should be used. The only time it gets specific is with the Web Content Accessibility Guidelines (WCAG), but the focus is more on scalability and contrast. Other helpful links like WebAIM or tools such Tanaguru Contrast-Finder can also help enable the designer to make and defend informed design decisions.

Shift patterns and process

Change is exciting, but it is also scary. Arguments on the long-term benefits and the financial arguments behind inclusive design are often unconvincing. Accessibility and inclusive design principals can be pushed aside when time and money is tight. Other priorities like meeting deadlines for press or the launch of an event come into play.

Everyone is busy. Everyone is stressed. Overwhelmed and under-supported staff cannot take into consideration the future or take the time to update their skills. Even designers who are aging or seniors themselves have trouble seeing the value altering their practice to meet the changing needs of the world. Disability and the aging demographic are not associated.

Without the time or support to upgrade skills and adjust to new ways of doing things, people will continue doing what they are familiar doing because it makes sense to them and feels like a better use of time than fumbling through unknown territory.

We all need time to grow and support one another in the learning process. It is not efficient for one designer to create a document and another designer to restructure it so that an accessible PDF can be posted online. The time efficiency of tagging documents within existing industry software like InDesign, running scripts to apply metadata as ALT text, or Action Scripts in Acrobat sound great, but if a designer has never done coding before, you might as well be asking them to get on a rocket ship to Mars.

Good design

Good design is accessible design. Design is about accessing information – whether that’s a dance theatre performance, or a budget meeting at a civic centre. This information can be presented in different ways. There is no one size fits all approach to graphic design – nor is there to accessibility.

There is great virtue and promise in inclusive design. Focusing on compliance is the wrong way to approach creative problems. Saying “I need to do this because the law says so.” isn’t going to bring around positive change. To get designers behind the AODA, we need to put the power back in the designer’s hands. We need to talk about accessibility in a knowledgeable way and make inclusion useful and practical rather than a burden.

Designers need to integrate new ways of designing into their projects. Two possible ways of doing this are by looking at the role of the graphic designer and the power they have through visual communication and how documents are created. To do this, there needs to be a shift in the pattern and process in which designers work in. The shift is a more complicated problem to approach – one that will need ongoing troubleshooting.

We can’t wait for everything to be perfect. We are designers. We are doers. However, the individual or the government cannot make a difference alone – we need to work together. Together we will build a better world for everyone.

Scripts for InDesign: Accessibility

Adobe InDesign is a common application used by graphic designers.

Scripts can be used in InDesign to help designers make accessible documents, and to speed up some tasks. Below are some free scripts that I have found beneficial:


This add-on by Stephane Baril allows for easier access to the necessary items to set up a tagged document in InDesign (CS5+).

Its also great when teaching yourself or others the steps to create accessible documents in InDesign.

Note: This requires an Adobe  Creative Cloud subscription.

Batch Apply XMP ALT Tags to EPUB and HTML Images

This Script by Marijan Tompa is very handy if you work for someone who puts the ALT text for Images in the XML: Headline or somewhere else in the metadata of an image. Instead of applying the ALT text to each individual image through Object Export Options, you can run this script to do it for you.

Note: When I tried to run this in CS6, the Script did not work unless I moved it from the Users folder to the Application folder. See forum post, All InDesign Scripts won’t work for further information on troubleshooting this problem.

Regular installation instructions can be found at How to install scripts in InDesign.


If you are looking for general information on creating accessible documents in InDesign, I suggest:

Action Script for PDF Accessibility: Automate Properties

When working with a lot of PDFs as part of your day-to-day work, scripts to automate regular tasks can come in really handy.

The instructions below will automate some of the tasks that are often part of the workflow when creating accessible PDF documents. The tasks I am focusing on for this Script are found under *Properties* in PDF documents in *Adobe Acrobat Pro* (not Acrobat Reader). They include:

  • Add Tags to Document
  • Show Document Title
  • Show Bookmarks
  • Set the document Language
  • Run Full Accessibility Check

These instructions presume that the document is tagged and that you/your client is filling out Document Title and keywords in the original document’s File Info. If this is not the case, you’ll need to add those manually. To find out how to do this, I recommend the Accessible Digital Office Document Project (ADOD).

Screenshot of Acrobat Pro, showing the View dropdown open.

Acrobat XI:

  1. View > Tools > Action Wizard
  2. The Action Wizard panel will appear on the right hand side of your document. Select “Create New Action” from the menu. A window will appear, showing you the available options for creating an Action Script.
  3. To automate Add Tags to Document:
    1. Accessibility > Add Tags to Document.
    2. Click “Add to right hand pane,” the green plus (+) icon.
  4. Set the document’s Description, such as the document Title (if in the document Properties in Word or InDesign) and Author:
    1. Content > Add Document Description
    2. Click “Add to right hand pane,” the green plus (+) icon.
    3. Click “Specify Settings”. A box will appear with fields and check boxes.
    4. Uncheck “Prompt Use.”
      1. Note: Most existing Action Scripts have this checked, which is helpful in scenarios like training. However, prompting can be annoying when you already know what your doing. By unchecking “Prompt User” you are letting the Action Script run through its tasks without you giving it further permission.
    5. Leave the check boxes clicked for the info you want carried over from the original document. If you want something different, for example the author being Company X rather than whoever wrote the original document, you can put Company X in the Author field.
  5. Set the Initial View, such as Navigation Tab (Show Bookmarks) and Show: Document Title (not File Name)
    1. Document Processing > Set Open Options
    2. Click “Add to right hand pane,” the green plus (+) icon.
    3. Uncheck “Prompt User”
    4. Click “Specify Settings.” Under Initial View, select Bookmarks & Page, and under Window Options, you’ll see Display Document Title. Select “Yes” instead of “Leave As Is”
  6. Set Reading Language:
    1. Accessibility > Set Reading Language.
    2. Click “Add to right hand pane,” the green plus (+) icon.
    3. Uncheck “Prompt User”
    4. Click “Specify Settings.”
    5. Select English from the language options. (if you often work with documents written in other languages, you can set up different Action Scripts for French, Spanish etc).
  7. To automate running the Full Accessibility Check:
    1. Accessibility > Full Accessibility Check
    2. Click “Add to right hand pane,” the green plus (+) icon.
    3. Uncheck “Prompt User”
  8. Once you have finished applying the necessary tasks to your Action Script, select “Save”
  9. Enter the desired name and description for your Action Script.
  10. And ta-da! You’re done!


Standardize Routine PDF Tasks

SCreenshot of the Edit Action script panel and the Manage Action Script panel in Acrobat DC

Acrobat DC

Acrobat DC comes with an Action Script called ‘Make Accessible’. However, you may not want it to do all the tasks it comes with (OCR, autotag etc) or prompt you at every step (inefficient use of time). You can either make your own Action Script, or create a revised version to suit your needs.

  1. Open Tools and scroll down to Customize.
  2. Select Action Wizard (Note: to add it to your sidebar in Acrobat for quick access in future, click ‘Add’)
  3. Select “Manage Actions” in the top navigation bar
  4. You will see a list of Actions. Select “Make Accessible” (default script) and select Copy.
  5. Enter a new or revised name
  6. With your copied script selected, click Edit.
  7. Select the actions you with to edit/delete and change as you best see fit.


Action Wizard (Acrobat Pro DC)

Create and verify PDF accessibility (Acrobat Pro DC)

WordPress Accessibility

Useful links on improving the accessibility of your Wordpress site.

I love WordPress. Its intuitive, easy to use, beautiful, and free. Sadly, it is not known for it’s accessibility…

As I am not a web developer, I haven’t crafted my own blog out of HTML and CSS with love and joy. Instead, I have been writing ALT tags and hierarchy into my code to make it as accessible as possible. Recently, I started looking into plug-ins to increase the accessibility of my many WordPress blogs. To my surprise, plug-ins are only available to WordPress.org sites – which requires you to have a unique URL and web hosting. So, I created another blog, a travel site in reaction to the success of my China blog, through WordPress.org to utilize WordPress’ accessibility options.

Here are some helpful links to guide you through the process:

The WordPress.org Process

To help you along in setting up your own WordPress.org site, here is step-by-step directions and documentation from setting up my own WordPress.org blog, The Black Beret Abroad.

Initial Set-Up

  1. Set-up a location for your WordPress (WP) installation (if it is a new website then you will need to arrange a domain and hosting).
  2. Decide whether your entire site will be WP or just a part of it.
  3. Load WordPress on your server.
  4. Go to your control panel to determine which database to run WP in.
  5. Input necessary information.
  6. Administer your new WordPress site by going to domain.com/wp-admin (if the entire site is WP) or domain.com/wpfolder/wp-admin (if WP is only part of the site).
  7. Log into your unique URL (ie: http://yourwebsitename.com/wp-admin/) and enter password. (Troubleshooting note: If you get an Error 500 message like I did, contact your server provider and they can fix it for you. Once they’ve fixed it, clear your browser history and re-attempt to log-in.)

Wordpress.org login page

Installing the WP Accessibility Plugin

Wordpress folder on server

  1. Go to the folder on your server where your WordPress folder is.
  2. Click the ‘wp-content’ folder in your WordPress folder
  3. Upload the ‘wp-accessibility’ plugin (link to download the plugin) to your ‘wp-contents’ folder.
  4. Log into your WordPress.org account through a web browser.
  5. In the left hand bar you will see ‘Plugins’ between ‘Appearance’ and ‘Users’. Click it.
  6. You should see WP Accessibility in this list. Select ‘Activate’ – and ta da, it is activated!

    Wordpress Plugin page.

As always, suggestions and comments welcome below. Thanks!