Categories
Accessibility Technology Uncategorized

Quirks in Web Standards, Browsers, and Screen Readers

This is my second session of the first day at the CSUN conference, and “takes a look at quirks and bugs in browsers and screen readers, what they mean for users, and how to avoid, fix, or work around them.”  (description is from the conference session guide).  As someone who is actively involved in building consistent web experiences (i.e. browser compatibility), I’m interested in how Ian does this when you add accessible technology into the mix.  Any misinterpretations of Ian’s presentation are entirely my own.  Any errata, please let me know!

Presenter:  Ian Pouncey, Accessibility Specialist, BBC (@IanPouncey)

 

RESOURCES

 

SLIDE ONE

Ian took some time to establish his credibility…

Used to work on the Yahoo! home page, and more recently has been a web developer at the BBC.  Been doing this for about 14 years.  Written a book about CSS from Wrox publishing.

Room was made up of developers, technical folks, screen reader users, and those obliged to come (a little humor).

Ian shared a few slides that were pretty humorous related to “skip to content” links, wherein the humor was related to where you placed the accent on the word content (hopefully he’ll post those slides).

 

SLIDE TWO

Shared a couple pages about skip links from Gez Lemon and Terrilll Thompson, and then demonstrated dynamic skip link code with window.location.hash.

 

SLIDE THREE

Ian showed form error listings and focusing on fields with errors.  Unfortunately, window.location.hash only works reliably in IE!

Ian did a demo of a skip link bug when using off-page content on iOS7.  He prefers using content off-top rather than off-left.  This technique however can result in some interesting behavior, notably showing the skip link after an up-swipe gesture to turn on VoiceOver, and then navigation after that makes the screen go completely blank.

Another option is to use off-screen CSS clipping, which unfortunately results in a lot more code.  This clipping technique is used on about 98% of the BBC web site, so if you want to see it at work, head over there 🙂

 

SLIDE FOUR

Next, Ian shared an ARIA landmark bug in iOS6.  This bug basically announces ALL landmarks in VoiceOver as simply “landmarks,” which is not very helpful.  This bug is resolved by adding a heading to every landmark.

 

SLIDE FIVE

Finally, Ian shared a bug with Live Regions.  You can’t always rely on live regions to provide information to the AT at the appropriate time.

Solution:  JavaScript-added content can be read once it’s been written to the screen.  So, you can build an empty div that quietly waits for content to be written into it.  Be sure to use role status with the assertive attribute.

Categories
Accessibility Technology Uncategorized

Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

This is part two of a two-part presentation.  Catch up on part one here:  Introduction to ARIA and HTML5, Part 1

I’m typing this introduction before the presentation begins, and as I understand it, this session will be more technical than the morning session.  I’m not sure how many in-depth code samples will be included (the resources link below hints at what we’ll be talking about), so I’m making an educated guess that I may not be able to capture every nuance.  My apologies in advance if this is the case.

Presenters:

 

RESOURCES

 

EVENT PLUG – TPGBB (The Paciello Group Bug Bash)

  • Wherein you and TPG can ID and squash AT bugs
  • Thursday, March 20, 5:30 – 6:30 PM
  • Suite 3233, Harbor tower, Manchester Grand Hyatt

 

 

STEVE FAULKNER’S SEGMENT

SLIDE ONE

Diving into some HTML5  – an overview of the session

Steve Faulkner talked briefly into his involvement with his having a role in the creation of the HTML specification.  His specific interest is in how APIs speak to AT.

 

SLIDE TWO

Getting Simple

Getting to use native HTML controls makes things simpler for the developers and the AT.

 

SLIDE THREE

HTML5 Demo – details/summary

Here’s an example of the “HTML code triangle” we’re all used to:

<details>

<summary> label </summary>

Some content

</details>

When fully supported, you’ll be able to use native HTML controls without having to use any complicated JavaScript.  In the example above, clicking details would expand and show the contained elements.

Steve then demonstrated in CodePen an example of the code above, and how vastly simplified it is to render these UI elements.  This will make UI/UX designer’s lives much easier.

 

SLIDE FOUR

Chrome, Opera, and Safari have implemented this

Keyboard = 1/2 implemented

 

SLIDE FIVE

Steve then gave a description of how the code above is exposed to the AT APIs (i.e. MSAA).   Put simply, it’s exposed as a <div>, however, it’s not an accurate description of how it’s represented within the DOM.  He then proceeded to show how this looks when viewed through the “Accessibility Viewer” tool.  The aviewer tool is an object inspection tool available from the Paciello Group’s web site at http://www.paciellogroup.com/resources/aviewer.

Not all information is necessarily passed through the API and readable by aviewer.  The hope is that every browser will expose the same API Names, Roles, and States.

 

SLIDE SIX AND SEVEN

What We Want

  • We want to be able to see what’s actually there.
  • We also want to fill the gaps in general support in FF, IE, and webkit browsers

 

SLIDE EIGHT

Steve showed and described the example above, only this time embellished with ARIA code inserted.

 

SLIDE NINE

Showed the details summary here as a working example:  http://www.html5accessibility.com/CSUN14/details.html

The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.

 

SLIDE TEN

Dialog

Creating a modal dialog that works with keyboard and prevents users from accessing ‘disable’ content is the holy grail…

Being able to do this within native HTML is something that sure would be awesome.  See next slide…

 

SLIDE ELEVEN

What we get for free:

  • Focus moves to modal dialog when displayed
  • Focus stays until it is dismissed
  • Content not in the modal dialog is really disabled
  • ESC key dismisses it
  • <dialog> = role=dialog

 

SLIDE TWELVE

What we need to add (this only works in Chrome with Canary plug-in at the moment)

  • Accessible name to dialog:  <dialog aria-label=”text”>
  • Currently when the dialog is dismissed, focus moves to <body> when it needs to move to control that triggered dialog display:  can be polyfilled using scripting.

Steve demonstrated accessible modal dialog, once again with CodePen; he was unable to tab “out” of the modal dialog.  It works like a JavaScript alert()

 

SLIDE THIRTEEN

The “good oil” on implementing custom dialogs (I didn’t capture these links, but they’re available in the TPG source slides from the “Resources” link above).

  • Juicy Studio – Custom Built Modal Dialogs
  • The Incredible Accessible Modal Dialog
  • WAI-ARIA design pattern – modal dialog

 

SLIDE FOURTEEN

Input type=number

What we get:

  • Correct role and value information
  • Keyboard operable

Exposed as spin buttons

 

SLIDE FIFTEEN

Input type=range control

Implemented in all browsers.  However, default styling in IE is pretty funky, and they all look different from each other.  Bottom line:  you get everything for free.

 

SLIDE SIXTEEN

There are conformance rules for HTML5, but they can be difficult to decipher.  Steve has a “Using ARIA in HTML” document available for download which can help.

 

SLIDE SEVENTEEN

A large part of what’s been consuming Steve’s life in his role on the HTML5 specification group is figuring out which ARIA Roles, States, and Properties can be used on any HTML element.

 

SLIDE EIGHTEEN

ARIA Validation

  • Use of ARIA in HTML5 is non-conforming and probably always will be.  It doesn’t make any difference, it still works.
  • Easiest method is to use the HTML5 DOCTYPE with ARIA markup and then validate it using the W3C NU markup checker:  http://validator.w3.org/nu/

<!DOCTYPE html>

 

KARL GROVE’S SEGMENT

SLIDE ONE

Live Regions

  • Allows user to be notified of content changes
  • Typically for content that changes automatically
  • Content change may exist separate to what has focus
  • Live Regions facilitate these notifications

ARIA overcomes gaps between what JavaScript has “traditionally” done in web browsers to emulate desktop applications.

 

SLIDE TWO

Karl’s favorite thing to say:  “What is this thing & what does it do?”

  • Chat, error logs, etc. (role=’log’)
  • Status messages (role=’status’)
  • Urgent message requiring immediate notice (role=’alert’)
  • Stock ticker (role=’marquee’)
  • Timer/Clock (role=’timer’)
  • Progress indicator (role=’progressbar’)
  • None of the above (role=’region’)

 

SLIDE THREE

How important is the content?

  • aria-live=’polite’ (waits patiently, default for most roles)
  • aria-live=’assertive’ (interrupts output, default for alert role)

 

SLIDE FOUR

What’s being changed?

  • I’m adding stuff (aria-relevant=’additions’)
  • I’m removing stuff (aria-relevant=’removals’)
  • I’m changing text (aria-relevant=’text’)
  • I’m replacing stuff (aria-relevant=’all’)

Makes relevant changes to the DOM within that live region.  You can change these properties together as needed.

 

SLIDE FIVE

What matters?

  • aria-atomic=’false’ (default behavior, only announces changed node)
  • aria-atomic=’true’ (presents entire contents)

 

SLIDE SIX

What’s my name

A redux of aria labels that was covered in Part One

 

SLIDES SEVEN AND EIGHT

<div role=’alert’ aria-label=”Errors’>

Please correct the following errors:

</div>

Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.

 

SLIDE EIGHT

Karl then demonstrated some of the challenges when using live regions with a chat he had set up at:  chat.karlgroves-sandbox.com

He also showed a web-based slideshow called “shower”

Download and play with Karl’s JQuery plug-in at github.com/karlgroves/jquery-live-regions

Short break here…

Karl went about soapboxing:

“ARIA is a LIE and your HTML doesn’t do anything.  They are instead a polite request to the browser about what to do with our code, which is then transformed into a DOM.”

Principle of Least Astonishment:  things should behave consistently

 

HANS’ SEGMENT

SLIDE ONE

  • Keyboard and Focus management
  • Form validation
  • Mode conflicts
  • Solutions, workarounds, and considerations

 

SLIDE TWO

Problem with Custom Controls (not native UI)

Usually created with generic elements like <divs> and <spans>

  • Not keyboard focusable
  • Have a default tab order
  • Behavior unknown

Best solution is to use native controls, or manually define keyboard focus and behavior needs.

 

SLIDE THREE

Keyboard Issues in a Nutshell

  • Reachability:  via tab order, globally defined shortcut, activating another widget
  • Operability:  all functionality should be doable via keyboard and mouse input.

 

SLIDE FOUR

To be accessible, ARIA input widgets need focus.

  • Tabindex=”0″ element becomes a part of the tab order
  • Tabindex=”-1″ element is not in tab order, but focusable

Each widget should have only one stop in the tab order.  All of your widgets should be reachable via keyboard.  Hans then gave a demonstration of a tree widget, tabbing both into and out of it using JAWS.  This demonstration also pointed out the danger of wrapping a page with a role of application.

An alternative for a roving tabindex is the aria-activedescendant=”<idref>”

 

SLIDE FIVE

Every widget needs to be operable by keyboard.  Common keystrokes are:

  • Arrow keys, home, end, page up, page down, enter, space, esc
  • Mimic navigation in the desktop environment when possible:  www.w3.org/WAI/PF/aria-practices
  • Always manage and keep track of your focus.  Never let it get lost.

To demonstrate focus, Hans showed a table that allowed deletion of columns of data.  After deleting a column, the previous column received focus.

 

SLIDE SIX

Skipping Mechanisms

  • Ability to skip content is crucial for screen reader and keyboard users
  • Skip links may be out of fashion and often misused, but users still need to be able to skip.
  • Alternatives:  collapsible sections, consistent shortcuts, custom focus manager

 

SLIDE SEVEN

Form validation

  • ARIA makes form validation easier to manage:  aria-required & aria-invalid states, role=”alert” flags validation errors immediately.  Inline and error summary used together are most effective.
  • Validation summaries make invalid entries easier to find

Create a programmatic connection between validation messages and their associated fields.  Maybe there needs to be a W3C specification about how AT is supposed to behave (there’s one for UA).  Hans provided a demonstration of a sample form with required fields.  Tabbing away from a required field activated the “required” error when tabbing into the following field.  He attempted to mark up the fields as live regions, but it didn’t work very well.

 

SLIDE EIGHT

Fallback solutions for link buttons

There’s no real consensus on links versus buttons.  Set role=”button” to make links look like buttons for screen readers

 

SLIDE NINE

Mode conflicts, i.e. Role=Application

  • Screen readers normally browse in ‘virtual mode.’  This means it navigates a virtual copy of the web page.  It intercepts all keystrokes for its own navigation (i.e. “H” for heading navigation.
  • For dynamic web apps, virtual mode may need to be turned off.  Interactive widgets need to define the keystrokes themselves; content needs to be live, not a virtual copy; automatically switches between virtual and non-virtual mode.
  • role=”application”:  screen reader switches to non-virtual for these elements; must provide all keyboard navigation when in role=”application” mode; screen readers don’t intercept keystrokes then, so typical functions will not work.

 

SLIDE TEN

Role=Document

  • For apps with reading or editing sections (e-mail client)
  • When applied to a container inside an application role, the screen reader switches to virtual mode.

Only use application role when your application actually IS a web application.

 

SLIDE ELEVEN

Explain to users how Rich Internet Applications work

Put some hidden text at the beginning of the page to explain.

 

SLIDE TWELVE

The perfect dialog, in theory

  • Use role=”dialog” combined with aria-labelledby (for dialog title), aria-describedby (for dialog message text)
  • Focus management
  • For modal dialogs:  prevent virtual navigation to background using aria-hidden=”true”

 

Categories
Uncategorized

Campus Readiness: Communicating IT Changes to the Campus Community

Title:  Campus Readiness:  Communicating IT Changes to the Campus Community

Presenters:

  • Jo-Ann Cuevas, Campus Readiness Specialist, Stanford University
  • Ammy Woodbury,  Campus Readiness Specialist, Stanford University
  • Christine Jacinto, Assistant Director of IT, Humanities & Sciences, Stanford University

 

SLIDE:  Campus Readiness at Stanford University

  • 28K constituents
  • About 20 client-facing projects released every year
  • 2 people responsible for getting the word out to the campus

 

SLIDE:  When an IT Need is ID’ed…

  1. A document management solution to facilitate collaboration and manage data security
  2. PM receives approval to start the project
  3. PM creates charter
  4. PM assembles team, including campus readiness
  5. Campus readiness reviews the charter
  6. Have a meeting to review the charter (impact, audience, training, marketing, documentation, communication).  Campus readiness forecasts hours based on the discussion.

 

SLIDE:  Communication Plan

A living document that’s updated frequently.  Focuses on communication across phases, IDs key stakeholders and end users.  This functions as a to-do list and a kind of “shadow project plan.”  Includes a running narrative and summary.

Four main sections to the rest of the communication plan:

  1. Awareness and engagement:  who do we need who will be informed about the project?  Might include help desk, key decision-makers, governance groups, administrative assistants, power users, and so on.
  2. Training and documentation:  all the elements we need to create for ongoing needs, current employees, new employee on-boarding.  Instructional designers decide on the best approach for training, because it will vary.
  3. Reinforcement and post-implementation feedback:  what does help desk need to promote for struggling users.  We use qualtrix for survey-taking.
  4. Ok, I missed one step here – my bad.  Can’t type fast enough…

 

Plan Execution

Includes a ton of work:  E-mail communication, hands-on training, surveys, change training, UX testing, documentation, service promotion, e-learning dev, campus communication, instructional design, user advocacy, presentations.

We function as the user advocate and engage in a lot of geek-to-English translation.

 

SLIDE:  Case Studies

Case 1:  Mobile Device Management

  • Early intervention led to iteration in the development
  • UX testing led to significant improvements in usability.
  • Adoption was strong
  • When adoption plateaued, Campus Readiness held user interviews determining that further improvements were largely out of Stanford’s control.  Promotion methods were altered to address those issues and use different approaches.

The dev team embraced Campus Readiness input as they saw the impact on adoption.  Team talked a bit about some bumps in the room with AirWatch and how they mitigated some of those issues.  UX issues are considered so important now that the team can delay roll-outs to accommodate needed changes.

 

Case 2:  Converged Communications VoIP Rollout

Change that affects administrators; on-site training that was all-inclusive accommodated client’s busy schedules.  We started with Humanities and Math & Science departments, then went campus-wide.  Phones would be on the desk after staff went through training, ready-to-roll.

It’s definitely a good idea to reach out to your connectors, ’cause someone is always the “go-to” tech helper in a department.

 

Case 3:  International Travel Data Security

It’s no longer just about visas and vaccines, it’s also about data security!  You have to be conscious of where your data is going.  We have three preferences of how we want people to work (in order of preference)

  1. What would we most like you to do?
  2. What’s a good approach?
  3. What’s the minimum required?

Their shop has loaner iPads for overseas trips.  If the user MUST take their own computer, it is imaged prior to departure and is restored upon their return (and PRIOR to the computer going back on the network).

 

Case 4:  e-mail and calendar upgrade

At launch, the campus readiness team provides:

  • Video tutorials (what’s new and different)
  • Daily tips by e-mail
  • Front-line support
  • Demos
  • Hands-on training
  • Campus partners

Each session had a roomful of people, since implementation of such a product affects pretty much everyone.  We would also engage with key stakeholders and representatives from each area to hear what their pain points were.  We would then help these “decentralized” folks formulate their own plans for communicating changes to their teams.  This helps build community.

 

A “Campus Readiness Specialist” has experience with:

  • Communications/business writing
  • ID and training
  • Presentations to large and small groups
  • Help desk support
  • e-learning development
  • UX testing

Key Qualities

  • Warm, friendly and outgoing style
  • Ability to rapidly learn new systems
  • be a geek-to-English translator

 

QUESTIONS

Are you a part of the PMO?  No, we’re matrixed but mostly report to documentation team.

What communication mechanisms do you use…Social Media?  We do use Facebook and Twitter, we also use an IT access page as well as a space for messaging on our ticketing page.  We also use the “Stanford Report,” a daily e-mail communication managed by university communications.

Do you participate in requirements gathering phase?  Yes!  But not always…

How many people normally attend your weekly monthly meetings?  Depends, from 40 or less on weekly meetings to 81 for monthly meetings.

 

 

 

 

Categories
Uncategorized

Big Data Enables Student Retention: Student Success & SAP HANA

Title:  Big Data Enables Student Retention:  Student Success & SAP HANA

Presenters

  • James David Hardison, DMD, MBA, Industry Principal, Higher Education
  • Vince Kellen, Ph.D., Senior Vice Provost Academic Plan Analytics and Technologies

 

SLIDE:  Screen shots of the “Powers of Ten” film

What if you could…(I smell a sales pitch coming)

  • Manage data, have the current data, have the right answers

 

SLIDE:  30 year old data modeling is slow and inefficient, in-memory is the new hotness!  (My words, not theirs)

HANA:  High Performance ANalytic Appliance

 

SLIDE:  HANA for Higher Education through University Alliances

  • SAP donates licenses to 1,300+ univesities
  • 1.2 million students educated on HANA
  • Certifications, etc.

 

SLIDE:  Newton’s Second Law of Motion

Students at risk are not likely to change their behavior without intervention.  Used snowball rolling downhill as an example…easy to stop at the top of the hill, but irresistible at the bottom.

 

SLIDE:  Using Fast Analytics to Help Improve Student Retention

High response rates to mobile micro surveys, about 40,000 responses in 4 weeks.  Questions include things like “how much are you working this term, how stressed are you (1-5 Likert scale), do you think you’ll be successful this term, etc.

In-memory analytics requires different architecting of the data modeling; We don’t do traditional ETL (Extract Transform Load techniques).

Took an approach of making data available, rather than keeping it “close to the vest.”

We can answer the question:  do we know how many left-handed Hungarian ping-pong players we retained?  How do we break our analysis into little pieces to answer practical problems and questions.

Also collecting “technographic” information on student device types and OS, frequency of use, number of devices, etc.

Been prototyping this with lecture capture and full-text search (what he referred to as “wayfinding”), i.e. ability to find specific terms, apply metadata, ability to link out to other materials, and so on.

Graph databases are generally not used by university degree audit reports, which precludes the use of “what if” scenarios.  This is useful for day-to-day business needs.  Incidentally, graph database technology is widely used in the Social Media space, but for some reason it seems to be all new and exciting to many of the wide-eyed higher ed attendees.  Hmm…

They’re using HANA data with Tableau to make pretty graphs.  Also, showed an Enrollment Plot of Chemistry 105

 

SLIDE:  Academic Health Notifications: View in Student Mobile App

 

SLIDE:  Using this data in a personalized student profile

 

 

SLIDE:  Taxonomy?  Automatic metadata?  Automatic atomic metadata?

  • Let learners navigate an a/v stream
  • Let the system learn what the top terms are.  Let the system map terms to concepts.  Let instructional designers lightly bump the taxonomy.

Thinking of Google AdWords-style presentation of information that’s relevant to the student’s click-stream and status.

 

SLIDE:  Organizational Considerations

  • Hired Ph.D. level data scientists (there was some turnover)
  • Translated old architectures to HANA and retired old IR data warehouse
  • Opened data, many have access, personal data is protected
  • Raised skill sets in colleges and units and provide support.

 

SLIDE:  Some best practices

  • Be safe and secure
  • Be collegial
  • Help improve data quality
  • Be open-minded and inquisitive
  • Share (don’t be a taker)

 

QUESTIONS

Do you plan to include co-curricular data into your system?  Obvious items are participation in clubs and organizations, and surfacing internships and job opportunities.  Yes, it’s on the roadmap.

Are you collecting data on effectiveness of tutoring?  Yes.

 

Categories
Student Affairs Technology Uncategorized

The Edward Snowden Affair: A Teachable Moment for Student Affairs and Higher Ed

The erosion of our collective privacy has been going on for a very long time.  Most of us are (sometimes grudgingly) comfortable with the exchange of our personal information for useful products and services.  The biggest problem most people seem to have with the revelations about the NSA’s surveillance program is that it can and does gather digital information about everyone, and can use it at any time for any reason.  The fact that a relative “schlub” in the organization can access and use that information is one of the main points Snowden’s whistleblowing meant to get across.  This got me thinking about how we use data in higher education.

In higher ed, we’ve been collecting lots of data for a long time, and we’re bound by law (FERPA, HIPAA, etc.) to protect and retain student data.  Our student information systems have detailed security policies outlining granular role-based access, aka which employees get to see which student information.  These policies are generally structured on a “need-to-know” basis.  Here’s my two-part question to the reader:  first, how many of us in higher ed have articulated a policy about the data we collect on our students and how we use it?  Second – and more importantly – how many of us have published such a policy that has been specifically drafted for our students?

Every Student Affairs professional I know wants to use data to help our students be successful.  When properly applied, it’s a boon to our profession.  It helps us determine our students’ interests so we can help them choose an appropriate degree program.  We know this reduces both time to graduation and major changes.  Data helps us identify clubs, affinity groups, and other co-curricular activities our students can participate in.  We know that co-curricular activity participation increases retention, especially among first and second year students.  In our day-to-day jobs, we regularly use student data to determine satisfactory academic progress, GPA, eligibility to vote in student elections, reporting of all kinds, and so on.  With the move toward self-service web applications, we’re increasingly presenting data to our students and shifting more decision-making responsibility onto their shoulders.  This is a great opportunity for us to educate students on how we use data to help them, while increasing transparency about their data’s use.

In my opinion, that last bit about transparency is the key element for higher education. There are no shortage of articles about “big data” tools and how organizations use them for competitive advantage (whatever that means).  However, the tools themselves don’t address the more fundamental nature of how we “connect the dots” between disparate data points.  We should inform our students how we use their information so they can make better choices.  We should teach our students how they can use this information to their advantage.  We should help students understand that they are the masters of their own data.  In the same way that Mint.com provides insight into how we spend our money, our student data should provide insight that lets students thoughtfully determine where they should spend most of their effort.

What do you think?