CSUN Day 1 Notes

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)

Goals:

• 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

Takeaways:

• 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

Itinerary:

Wednesday, March 23:

Morning:

9:00am:

• First choice: Converting and publishing PDF documents to WCAG 2.0 compliant HTML (Harbor Ballroom F, 2^nd FL)
• Second Choice: Social Media Accessibility (Promenade AB, 3^rd FL)
• Third Choice: Accessible Images and Beyond (Solana Beach A, 3^rd FL)
• Fourth Choice: Using Visual ARIA to Physically See and Learn How ARIA Works (Harbor Ballroom, 2^nd FL, Harbor Tower)

10:00am

• First: The WordPress Way: Backwards compatibility & Accessibility (Mission Beach C, 3rd Floor, Between Harbor and Seaport Towers)
• Second: Digital Accessibility Legal Update (Harbor Ballroom F, 2nd Floor, Harbor Tower)

11:00am:

• First: WCAG 2.0 Success Criteria and Conformance Requirements for Documents (Hillcrest CD, 3rd Floor, Seaport Tower)
• Second: Creating Accessible Social Media Content for All Users (Mission Beach C, 3rd Floor, Between Harbor and Seaport Towers)
• Third: The Current State of Play: Screen Readers, Browsers, UI Frameworks and HTML (Hillcrest AB, 3rd Floor, Seaport Tower)

Afternoon:

1:20pm:

• First: 7 Essentials for Constructing Accessible and Usable PDF Forms (Hillcrest 3^rd FL, Seaport Tower)
• Second: Understanding and Advocating for PDF/UA – Karen McCall (Hillcrest AB, 3rd Floor, Seaport Tower)
• Third: Building a Digital Accessibility Program (Harbor Ballroom, 2nd Floor, Harbor Tower)
• Fourth: Humanizing the need for inclusive design (Mission Beach C, 3^rd FL)

2:20pm:

• Firs: Designing Accessible Workplace Applications (Harbor Ballroom G, 2^nd FL)
• Second: Digital Accessibility Best Practice (Mission Beach C, 3rd Floor, Between Harbor and Seaport Towers)
• Third: One Step Alternative Format Automation (Harbor Ballroom G, 2^nd FL)
• Fourth: Creating Accessible Documents with Google Docs (Harbor Ballroom, 2nd Floor, Harbor Tower)

3:20pm

• First: Accessible Bar Graphs in HTML and CSS (Solana Beach B, 3rd Floor, Between Harbor and Seaport Towers)
• Second: Usable Instructional Materials Made Easy (Hillcrest AB, 3rd Flr, Seaport Tower)
• Third: WAVE – New Rules, Enhancements, and Future Plans (Cortez C, 3rd Fl, Seaport Tower)

4:20pm

• First: The BBC, a Public Service Accessibility Story; Past, Present and Future (Torrey Hills AB, 3rd Floor, Seaport Tower)

Advertisement