Tag: a11y

Categories
Accessibility Technology

CSUN 2014 Web Track Mega Post

As usual, I like to make a post that sums up my entire conference experience…I call this the “Mega Post.”  As you may have guessed from the titles of the sessions I attended, I’m interested in the web track.  If the web is your bag, you just might find all this helpful.

Enjoy!

 

Friday, March 21

 

Thursday, March 20

 

Wednesday, March 19

 

Tuesday, March 18

 

Monday, March 17

Categories
Accessibility Technology

How to Win the Accessibility 3-Legged Race

This is my second session from the third day at the CSUN conference.  This description of this session from the event guide says that “We need accessible web products from our design agencies.  How do we make sure they deliver on that?  We provide practical advice drawn from experience.”  These guys definitely have the best session titles, and all their sessions I’ve attended were entertaining and had great usable content.  The very first slide has My Little Pony, so we’re definitely off to a strong start.  This might be my last post of the conference, since I have a train to catch.  Onward!

 

Presenter:

 

RESOURCES

 

George and Billy talked a bit about themselves and what they do.  They then said they’d help us with the often awkward “agency-client handshake.”  #awkwardhug

 

Agenda

  1. Set yourself up for success
  2. Create strategy and stick to it
  3. Be realistic about your team’s a11y knowledge
  4. Use testing tools AND test with users
  5. ABC always be closing

Round-the-room discussion

 

If you ask a simple question as a client like “is the product keyboard accessible” and they come back with Ctrl-Shift-Alt-F2-w-t-f”  That will tell you a lot about the company.  Common excuses and comments:

  • An excuse is “on our web site we sell ___ so blind people will not visit our web site.
  • Accessible web sites are ugly

 

Set yourself up for success

  • Ask lots of questions.  Early on.
  • If you see a lot of checklists early on, that is often something to be concerned about.
  • If you’re in an AGENCY:  “we need an accessible web site” is not a good requirement.  Read between the lines…is it a legal requirement, or do they have corporate buy-in?  What if you’re the only agency who is successful in delivering accessible web products?  Make it something that you can sell, list it on your web site!
  • If you’re a CLIENT, talk to your peers.

 

Create a Strategy and Stick to It

  • AGENCY:  work the client to develop milestones and figure out how to get there.  Make it an integral part of your workflow, it’s becoming a competitive advantage.  Bake it in at every stage.  Your account/project manager needs to clearly articulate how accessibility is done.
  • CLIENT:  ask one question:  what’s your accessibility strategy?  Pro tip:  if you have style guides / development guidelines that include accessibility, share those with the agency.  Compromise is OK as long as it’s realistic.

 

Be realistic about your team’s accessibility knowledge

  • AGENCY:  use your strongest web guy for the job; your SharePoint guy ain’t gonna cut it!
  • You need your whole team to know accessibility.  Teamwork, not “the one guy who knows VoiceOver”
  • Start small, ask your team to take the short online AODA / Customer Service course (a google search will turn this up).  Pro tip:  put a requirement in your RFP that the agency must take  this course.  It won’t make them experts, but it will give them a baseline knowledge.
  • CLIENT:  testing only with screen readers is not going to cut it.
  • Make sure you’re comfortable with the agency’s accessibility knowledge.  Don’t get into meetings / calls with the sales team, ask for the PM, BAs, designers, etc.  Ask for examples of their work with other accessible projects.  If the agency has no proven knowledge of accessibility, hire a third party.

 

Use testing tools AND test with users

  • Find the testing tools that work for you and use them.  It needs to be a part of your workflow.
  • AGENCY:  Test with users with disabilities.  You don’t need to invest in expensive testing tools. Just turn on VoiceOver on your Mac or High Contrast Mode in Windows.  Other tools we recommend are WebAIM WAVE toolbar, aViewer, Web Accessibility Toolbar, Color Contrast Analyzer, etc.
  • CLIENT:  Test with users with disabilities or at least simulate with assistive technologies.  Use automated testing tools, especially for regularly-posted content.  Be smart about prioritizing:  1 big issue on 1 page versus 1 small issue on 80 pages.

 

Always be Closing

  • “We’ll just do it in phase 2” never happens
  • Use MVP (minimum viable product) for accessibility
  • Write a report that clearly depicts the accessibility results.
  • Do good work and don’t be afraid to show the client you can do it again, this is your chance to articulate that in the report.
  • CLIENT:  spot-check, then sign-off on it.  It’s better to launch with some accessibility issues than not launch at all. Planning for some remediation is OK.  Ask the agency to report on the results of their accessibility strategy/work completed.  HINT:  you don’t actually care how they report.  Major benefit?  You flip the accessibility process upside down!  You’re basically asking for two things:  do the accessibility work and tell me about what you did.
Categories
Accessibility Technology

Lessons Learned: Accessibility Theory vs. Implementation Reality

This is my fifth session from the second day at the CSUN conference.  This description of this session from the event guide says that “standards-compliant accessibility does not always work as expected in real-life implementations…TPG/CGI will share techniques for dealing with inconsistent support by browser and AT products.”  If it’s anything like the other TPG presentations, there will be lots of content and resources…I will do my best to keep up 🙂

Presenter:

  • Hans Hillen, The Paciello Group (@hanshillen)
  • Jennifer Gauvreau, CGI
  • Stephen Cutchins, CGI

 

RESOURCES

 

It SHOULD work versus it DOES work

CGI and TPG have been working together for about two years and made a choice very early on that they would adopt WAI-ARIA and HTML5.  They’ll cover 3 use cases:  theory, use cases demonstrations and workarounds

 

Browsers and Screen Readers

  • Time + Budget = Targeted Testing Profiles.
  • Profile 1:  Win7, IE8 and IE9, JAWS (v12, v13, v14)
  • Profile 2:  Win7, FF, NVDA (latest stable build)

 

ARIA Landmarks

  • We weren’t using landmarks and wanted to use them.
  • Theory:  We had heard that it was easy to implement on existing and new pages, supported regardless of (X)HTML version, a real win-win
  • Reality:  initially worked as expected; as real content was added, strange things started happening.
  • Hans then showed what code looks like both with and without landmarks, and followed up by demonstrating with JAWS 12.  When a field is focused and does not have an aria-label on the region, JAWS (v12) reads the entire content of the main landmark.  IE used all the content of the region as fallback content.  Solution:  add an empty title=” ” tag in the body.

 

JAWS 13+ announces region before each form field

Solution:  wrap the fields in a <div> or <form> and define role=”form” on the form container.  JAWS stops announcing “region” before announcing the form element, but new issues sometimes appear.

Pair new HTML5 <main> element with ARIA role=”main”

  • Adding landmarks wasn’t necessarily guaranteeing a great and consistent user experience.

 

ARIA Landmarks: Lessons Learned

  • Need to test at a unit (landmark) and integration (page) level
  • Do no harm
  • You may not run into these issues if you have simple static content.  Most of this stuff crops up with forms and CMS-generated content

 

ARIA Dialogs: a common design pattern

  • Theory:  WAI-ARIA dialog requirements describe this in detail; it worked as expected with test content.
  • Reality:  when adding large sections of complex content to a dialog, things didn’t work as expected.  What would happen is that the dialog would display the contained content halfway down and focus would be on an element far down the page.

Question:  as a fix, could you make the close button the first focusable element?  Answer:  Yes, but there was a reason why we didn’t go that route (although I can’t remember what that reason was).  Instead, we made the heading of the dialog the first focusable element (tabindex=”-1″).  You can also force the dialog role so that it is read in “document mode.”

ARIA Dialogs: Lesson learned – adapt to design challenges

  • Create POC early on using “real world” content, not short strings of boilerplate text
  • Expand design patterns and authoring best practices to meet new design realities
  • Support the use of reusable frameworks like JQuery UI to design/build once and then reuse from a centralized solution for ease of maintenance

 

Use case 3:  Icons

Define alt text to make HTML images accessible is perhaps the first accessibility concept every developer learns.  However, as web designers and developers have embraced new methods for displaying icons, we were faced with a new set of accessibility challenges to consider

Requirements:  equivalent text content for  icons used to convey content, status or meaning; allow for user personalization; clients and developers need cost-effective scalable solutions.

Reviewed high contrast mode and user-defined style sheets

  •  HTML images should be used for icons conveying information.
  • CSS background images should not be used to convey content and only used for decorative images or as a redundant visual cue for adjacent text.

Designers prefer CSS image solutions (sprites) because they load faster.  Unfortunately, HTML images don’t inherit high contrast theme.  No fallback text for CSS background images.

Solution: build a High Contrast Mode detection script and use font-based icons.

Test your icon approach

Takeaways:always test your solution in high contrast mode, user defined stylesheet, images disable, css disabled

 

Key Themes

  • Do no harm
  • Adapt to design challenges
  • Be maintainable
  • Be vocal:  id bugs and tell vendors
Categories
Accessibility Technology

Oh, Canada? An Overview of Accessibility in the Great White North

This is my fourth session from the second day at the CSUN conference.  This description of this session from the event guide says that “When you combine developer attitudes with government legislation and online media, the results are uniquely Canadian perspectives on the state of digital accessibility.”  I wonder if this means that all their perspectives are extremely polite and amiable?  We shall see…oh wait, I just spied a picture of Justin Bieber in the slide deck.

Presenter:

 

Two perspectives:

  1. What’s happening in industry and broadcasting/publishing in general
  2. Legislative perspective

 

Legislative perspective in 2007/2008

We didn’t really have much.  At federal level, we had committed to WCAG1.0 until WCAG2.0 was adopted later.   The private sector’s timeline was a bit different, which Billy will talk about later.  Ontario largely led the charge, followed by Quebec in 2011.  Until recently, there wasn’t much happening that you’d hear about in the international media.

Patrick talked about the results of his 5 year media review (2009 – 2014) of about 15 major sites in Canada (including CTV, CBC, The Weather Network, Canada.com, Toronto Star, etc.).  He reviewed top sites for accessibility on forms, multimedia, tables, structure, clear, focus.  2009 only 7.8% of all tests were satisfactory.

 

Billy talked about the development side of the equation.  In 2009, accessibility was mentioned, but rarely practiced.  WCAG2.0 was only recently published as a recommendation.  Developers were busy building carousels, modals, tabs, and other features that would grow to haunt them later.  The situation was bleak!

 

Denis then picked up and talked about his experience getting up-to-speed on legislation in 2009.  He contacted all of the provincial governments to find out what they were doing.  He asked the following 6 questions:

  1. Are there any specific web accessibility standards set for your country/province?  (Mostly no)
  2. Are these standards abased on existing W3C accessibility guidelines?  (Yes)
  3. What conformance level if any is expected for these standards?  (mostly level AA)
  4. Are there any implementation deadlines planned for compliance?  (Mostly no)
  5. Do these standards apply only to government web sites?  (Mostly government web sites)
  6. Are the standards enforced as mandatory policies or just as recommendations? (Mostly recommendations)

The responses allowed Denis to build a ranked grid of sites, with ratios of errors to pages.  This was interesting.  He also transcribed these ratios into a heat map of the actual map of Canada.  This was really interesting.

 

Patrick then took the mic to talk about the 2014 web sites assessment.  This time, 27% of all tests were satisfactory, based on the testing criteria.  The upshot is that ALL CRITERIA IMPROVED.  This is a big deal, but still a long way to go.  Patrick fielded a number of questions about the tests.  Denis answered a question regarding web accessibility for organizations that have a web presence in Ontario (those with a presence over 50 employees).

 

Billy then talked a little bit about today’s community.  Informal poll shows that accessibility is still overlooked by some agencies.  It’s not mentioned as a service, and is rarely mentioned in past work.  However, accessibility camp attendance is WAY up.  AODA is probably driving a lot of involvement.  Developer attitudes are very positive.  Meetup groups are gaining in popularity, and developers outside of the accessibility community are speaking about it.  Our camps and Meetups fill up immediately…and we have waiting lists!

 

Denis asked session attendees if they would share some ideas about what they think the future holds for web accessibility.  Elle Waters said that their company is seeing fewer requests from clients requesting assistance with compliance-related issues.   George talked about his concern that accessibility is still aimed at organizations and governments, not individuals.  A comment was made about the law in Canada not having too much wiggle room and “not enough teeth.”  Some municipalities are actually actively avoiding compliance with the law or putting it off.  In some cases, Canada is looking at litigation in the United States as actually being a good thing that can spur action.  Denis wrapped up by saying that our aging populations will likely be a driving force in adoption of and demand for accessibility.  By 2061, over 1/3 of the population will need accessibility.

 

Online Media Future

  • Room for improvement
  • Change is happening
  • awareness still needed
  • legislation is making an impact
  • improving development culture

 

 

 

Categories
Accessibility Technology

A Pattern Library as a Foundational Sketch for Web Accessibility Efforts

This is my seventh session from the first day at the CSUN conference.  This session covers LinkedIn’s DaVinci UI Pattern library, which “…demonstrates accessible web patterns that designers and developers can combine into a work of art.”  I’m a big believer in the idea that having published standards can help guide an organization to be consistent with how they do things across channels.  Very much looking forward to this session.

Presenters:

 

RESOURCES

 

SLIDE ONE

Some details about LinkedIn and their mission statement…

 

SLIDE TWO

Accessibility Task Force

  • 12 cross-functional team members
  • Design, web dev, iOS engineering
  • Weekly meetings
  • Review designs and code in progress
  • Working a prioritized backlog of enhancements in existing products

Scrum-style process.  We’re building out a group of full-time professionals to help us with accessibility.

 

SLIDE THREE

A set of pictures that highlight LinkedIn’s mission to help everyone

 

SLIDE FOUR

Getting leverage

  • Company has 1000+ developers
  • Size of dev team has tripled in 2 years
  • Leverage methods

A driving question:  how can one person (or a small team) effectively communicate with such a large development team?

 

SLIDE FIVE

The DaVinci Pattern Library (brings together art & science)

  • Online library of UX patterns for web and mobile
  • Design variants documents
  • Dev implementation documented
  • Accessibility notes (when appropriate)
  • A common language

LinkedIn is considering open sourcing this…”dust” framework and “archetype” are already available.

 

SLIDE SIX

Library overview

Have several sections to their library; there are separate sections for mobile and desktop.  Each section has samples with “exemplifiers” that highlight what it actually looks like in action.

“Patternable things” can be contributed to the library after at least two development teams have done something that looks like – and they have been identified as – a pattern.

 

Drew took over and reviewed the iconography the site uses.  They’re switching to use webfonts now instead of sprites because they scale better and are much smaller in size.  They also have an accessibility that explains how the icons should be coded so it is properly represented by screen readers appropriately (and not read out loud as unicode).  Drew then spoke a bit about dialogs and how they should look (modeless and modal).  Dialogs are given focus, are dismissed by the escape key, and place focus back on the previous element after dialog is dismissed.

 

Sarah then talked about the slider control, an emerging pattern at LinkedIn.  It can be used with numeric values ranges and also discrete values i.e. for privacy (more open, default, private).  Arrow keys move it one increment, while page up/down moves 10, home/end keys move to lowest/highest values respectively.  Both HTML samples and Dust partials are available for implementation to internal developers.

 

Drew then described how forms are implemented.  Stacked forms are preferred to “sided forms” because some languages are more verbose than others.  They’re replacing JavaScript select boxes, which is saving load times.

 

SLIDE SEVEN

Sarah talked a bit about Future Patterns

  • User cards
  • Drop down/overlay controls with full aria
  • Global and page-specific keyboard shortcuts
  • iOS7-style toggle to represent a checkbox

 

Q & A

Question:  How old is DaVinci?  Answer:  about a year and a half.

Question:  This is a lot of overhead, is it worth it?  Yes, developers are expected to deliver value horizontally and contribute to this.

There were a number of really great questions about practical implementation details as well, sorry but I didn’t catch ’em all 🙁

%d bloggers like this: