i.e. the most available and accessible frames are the most likely to influence public opinion

"In general, it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content."

https://www.w3.org/TR/WCAG20-TECHS/G200.html

site audit tool

This article brings up the important issue of accessibility as a barrier to technology integration. It is suggested that accessibility should be a much more pressing concern than technological relevance to a lesson plan. First it is important to know whether or not all students will still have equal access and ability to reach mastery with the deliver method provided.

Rating: 7/10

Cupper: An Inclusive Documentation Builder

Simulation alone might have opposite of intended effect— participants might end up feeling negatively about the disability being simulated.

However, if framed with an appropriate conversation, the simulation can have positive effects and build empathy

Co-design: empowering users to make design decisions

Challenges

• Timing: a11y often not considered until too late in the design process
• Budget: when retrofitting for a11y, creates cost issues

Perception

• Calling co-design sessions "meetings" appealed to the company culture & made it seem more casual. Team was more open to the idea this way.

Measuring success

• Scope & compliance: how much of product is compliant?
• Shared responsibility: does everyone in the product lifecycle feel a sense of responsibility for a11y?
• Open lines of communication between designers and devs & users with disabilities

• Remember that subtitles and captions are not the same! Subtitles = just transposing spoken parts. Captions include sound effects.
• Lack of QA for captions is ableism

How to make captions better

• Special training is required - not just anyone can do this -Captioning should be a discipline within media & comms studies
• For sounds: it's significant if it contributes to the purpose of the scene. Background sounds, even if loud, are not always necessary!
• Also, sometimes silence is necessary to point out to create appropriate atmosphere
• Pay attention to idioms and make sure they're spelled / punctuated properly, otherwise it'll trip up the reader
• Fact checking is necessary to make sure sounds are being described properly (sirens vs factory whistles, as an example)
• Be exact about music playing - include song title, artist, and lyrics
• Make sure captions aren't obscured by background

How to set page titles with React

• default behavior: page title not updated and not announced to screen reader
• use document.title property to display name after load (Note: this might be useful info for Hypothesis to provide to publishers / page owners once we had support for SPAs)

Managing focus during page load

• don't use document.getElementById because it doesn't work reliably
• use React Ref API, set focus on the div after the page is fully loaded

• Both tab order and screen reader order follows DOM order. Changing visual order with CSS grid has no effect on DOM and therefore screenreader. Can make things confusing for keyboard users, users of screen magnifiers.
• Change source order, not visual order
• Test all layouts with keyboard to make sure focus order is as expected
• Don't compromise on semantics for visual order

WCAG 2.1 Requirements:

• 5 examples of websites meeting the requirement, at least 2 meeting AA and 1 meeting AAA
• For each criterion, there needed to be at least 2 examples of how to implement
• Documenting and testing procedures

History of Success Criterion 1.3.5

• Personalization: tailoring aspects of UX to meet preferences or needs of user
• Buttons, controls, links, inputs, can be modified/personalized by user --> First, identify purpose

Technical needs:

• publicly published metadata schema
• means of attaching metadata at the element level
• demonstrate value of attaching the metadata

Personalization task force formed to work on:

• taxonomies for semantics, help & support, and tools
• in the future: implement a "numbers-free" mode for users with dyscalculia
• work is being tracked in personalization-semantics repo
• Seeking feedback on vocab list
• HTML5 autocomplete attribute can be used to hint to user how to or whether to provide information --> provided a taxonomy for 2.1

Extensions for SC 1.3.5

• One that adds commonly used pictograms for certain words
• One that presents a compact list of all autocomplete fields on the page (could help with security concerns re: off-screen inputs)

• AT: single switch. Anything with just a simple on/off switch. Could be a button, tube to blow into, etc (like what Steven Hawking would use!)
• Consider that cognitive disabilities might be present in addition to physical ones.
• “Games represent access to recreation, culture, and socializing. The difference between existing and living.”

Recent advancements:

• Nintendo Switch introduced color inverting and greyscale options. First time in history every major gaming system has some level of a11y integration!
• Xbox has adaptive controller which allows you to completely remap controls in any way you want.
• GameCritic now includes screenshot of what subtitles look like and screenshot of game controls. Allows someone to know whether they’ll be able to play the game.
• Ubisoft now does FAQs for a11y features in games.
• EA Sports also surfacing a11y info and publishing manuals in screen reader accessible format
• Publish a11y info in advance of game release so AT users can decide whether they’ll buy the game ahead of time.
• Consider addition of “stress free mode” where users can play without worrying about failure (see: Barbarian)
• Madden 18 added haptics (in addition to preexisting announcer feature) to make the game accessible to blind users
• Auto camera tracking removes need to use right joystick when walking
• Customizable subtitles!!!!

• Wireframes are only visual, meaning devs are responsible for figuring out how the product behaves for all non-sighted users
• Designers need to create comparable experience for everyone who uses the product
• Include WCAG-compliant guidelines re: color, contrast, focus states, etc in your design system
• For wireframes, mark up header, main, and footer sections so devs know to use appropriate semantic roles
• Focus order: designers should draw the path of focus order for devs
• Tip: get the NVDA list of elements to see links and buttons out of order, see if it still makes sense
• WAI-ARIA cheat sheet by Karl Groves
• Create a table where each element of the page is listed. Create columns for role, properties, and any state changes

"Simulators are not for validation. They're for ideation. We don't roleplay disabilities." <br>–@LadieAuPair, #a11yTOConf

— Eric BooOOOooley (@ericwbailey) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

Accessible interior design for labs: adjustable lighting, high contrasting furniture on dark carpet, and chairs that are sturdy but easy to move #a11yToConf

— Nell Chitty (@NellChitty) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

"Leverage capitalism" for alt text for objects in virtual environments. In 3D marketplaces, objects are labelled for search discoverability; we can reuse these labels in virtual spaces, too, to identify what these objects are. Great recommendation from @TechThomas at #a11yTOConf

— Cordelia (@cordeliadillon) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

#a11yTOConf @TechThomas<br>Add alternative text; use the object name from the marketplace. pic.twitter.com/6GpuHgqqAR

— Adrian Roselli 🗯 (@aardrian) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script> 

Allow users to disclose and store user preferences, including accessibility considerstions, for 3D excited experiences. @TechThomas, #a11yTOConf

— Eric BooOOOooley (@ericwbailey) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

A-Frame GUI Examples #a11yTOConf https://t.co/Kr6RgLSoPa

— Nell Chitty (@NellChitty) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

#a11yTOConf @jessebeach shows a function that loops through a pre-defined list of valid ARIA roles as part of a React linting process. pic.twitter.com/BkxdLtotSK

— Adrian Roselli 🗯 (@aardrian) October 16, 2018

<script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

• AOM = accessibility object model. Proposed new collection of JavaScript APIs for web a11y being worked on by Google, Apple, and Mozilla
• Goals: fill in ARIA gaps, expose computed properties, enable a11y for custom-drawn UI

Fill in gaps with ARIA

• Work toward attribute and property parity.
• ARIA is string-based which makes working in JS inconvenient, AOM is working to fix this
• Also, components should have built in semantics, rather than devs needing to remember which to set (& risk having browsers set them incorrectly)
• Read more
• Map actions to DOM events
• Add new InputEvents types (currently designed primarily for text editing; need increment/decrement/dismiss events)

• CAPTCHA is difficult for elderly people, especially if English isn’t their first language. But also conceptually: if they’re being asked to provide birthday and other personal info, why are they then asked to prove they’re not a robot?
• A lot of tech is created by young, able-bodied people and as a result for them. Who gets excluded?
• 15% of the US population is over the age of 65 as of 2017. Will increase to 22% by 2050. Older adults are a rapidly growing user base
• Many older adults are low income or house less, therefore using older / outdated devices
• Arthritis, low dexterity, tremors among common concerns for older adults

Design principles for older adults:

• Provide more than one way of performing an action (I.e. opening an app: double click, voice command...,)
• Don’t add time-based pressure
• Large tap targets (48px minimum), generous margins between targets, consideration of action order (don’t put trash too close to save!)
• Outline tap targets clearly so users know where to tap (button outlines, form field outlines, etc)
• Allow for user to easily recover from mistakes
• Strong color contrast
• Tooltips help a user know they’re about to interact with the correct thing
• Avoid thin fonts
• Don’t use the same icon for multiple meanings across one app
• Describe functionality and key concept in plain language. Provide as much documentation as possible, but make it contextual
• Make sure navigation patterns are consistent and intuitive
• Half of seniors write down a list of steps for how to use a website. Redesigns, even small ones, can present significant challenges for seniors.
• Provide a reliable experience so users don’t have to re-learn interaction patterns

• Minimum Compliance Approach: using baseline a11y standards as the only method for inclusive design. Example: something can have an 88% WCAG compliance, which is pretty good, but still be unusable to a blind user.
• Actual interviews/user testing with disabled users is necessary in addition to standard compliance work. “Move past the minimum”
• Don’t just diagnose. Consider social context in which tech is used. Example: blind people tend to go with “low tech” solutions like canes and dogs because more high-tech options make things socially awkward for them.
• People consider if a technology can serve them combined with how it will serve them. Does this fit with my sense of self?
• Consider how a product might work in a user’s day-to-day life. That means you need to know what the day-to-day life is like for a user with disabilities.
• When setting success criteria, ask how your definition of success could limit someone’s ability to be successful. Consider remote sessions instead of F2F. Don’t assume lack of eye contact or verbal feedback = disinterest

• Neurodivergence = having a brain that functions in a way that diverges from the dominant societal standards of "normal." Covers a large scope of cognitive disabilities: autism, ADHD, and more
• WCAG does not have a lot of guidelines for people with cognitive disabilities bc the landscape of neurodivergent minds is so complex and diverse

Moving content:

• A chat bot that pops up could be helpful to a neurotypical person, but for someone with sensory/distraction issues, it's a barrier
• Sliding text across the screen can pull attention away from subtitles

Subtitles

• Language processing disabilities: some need speech + captions, some get distracted by captions and can't understand speech. Subtitles should be configurable
• If subtitles are paraphrasing rather than exactly as spoken, that's confusing for someone listening and following along with captions

Voice to Text

• Think beyond people with motor disabilities. People for whom English is not a 1st language or people with dyslexia / other cognitive disabilities are helped as well.
• Don't disable voice to text for any reason!!
• Google Docs' VTT works well and is an example to look at.

Working Memory

• Display password option in login form fields (note to self: does H have this??)
• "Remember Me" and password autocomplete reduces cognitive load for those with working memory issues
• Don't block access to password management software like LastPass

• The A11y Project
• Is it beautiful? Is it useful? Let’s not sacrifice the latter in the name of the former... focus styles are regarded as ugly, but many people rely on them!

What makes a good link?

• affordances like color, underline, hover states
• Focus style! Every browser has a fallback state for when they are not specified by author. But these defaults aren’t always good enough for WCAG standards.
• Don’t shift layout when styling for a link state!!
• Check focus styles in high contrast mode to make sure they’re still visually distinct
• Focus-within pseudoclass is useful for tables where cells contain links
• Don’t make assumptions about how people use their devices. If someone is on a mobile device they might still be using a keyboard!

• A11y is not a static state— every time new code is added there is a risk of losing a11y
• Sustaining a11y: what are the risks in maintaining? What are the challenges to keep it? Who has the power to support maintenance of a11y?

Risks to A11y

• Critical employee turnover, when 1 or few people are passionate about a11y and then later leave. Suggestion: promote active internal discussion for problem solving as a means of externalizing employee knowledge.
• Inadequate a11y training. Suggestion: provide usable and useful training resources. Rather than long courses or workshops, consider just-in-time resources (i.e include instructions for installing & configuring a11y software with instructions for setting up dev environment)
• Changes in regulatory requirements. Suggestion: create a11y SMEs in all areas of the organization, not just design or engineering
• Inadequate oversight in product management
• Loss of technology interoperability

Organizational Commitments

• prioritize a11y as a core value
• Support employees in creating knowledge assets
• Invest in infrastructure for knowledge management

Overview of laws at the provincial and federal level in Canada

• Provincial: Ontarians with Disabilities Act. Other provinces are now following suit with similar laws. Lesson from Ontario: passing a law is one thing, getting it implemented is another thing entirely. Govt has currently frozen a11y efforts pending “briefing of new government,” which was elected over 100 days ago.
• Federal: Accessible Canada Act. A good start, but is a weak bill (no timelines or obligations). Currently fighting for concrete timelines.

Lessons learned

• Accepted wisdom: a11y should be implemented for govt first, then large private sector corporations, then small private sector companies. However, it’s much easier for small companies and orgs to implement changes, so these should be tackled first.
• If there’s no deadline, there’s no pressure for action.
• Don’t splinter the power to make standards & access to enforce them. Creates inefficiency and dysfunction.

• Common metaphor: data visualization = a story about data. More helpful: it's a user interface for data. Data visualization IS accessibility technology. Helps people with and without cognitive disabilities by reducing effort required to interpret data.
• The idea of helping a user interpret data isn't inherently visual. "The purpose of visualization is insight, not pictures"
• Cognitive load: how much effort is required to understand something. Germane cognitive load: brain looking for patterns within clutter to determine context. Serial tasks cost more cognitive load than parallel tasks
• Pre-attentive attributes ideal for visual data representation: size, 2D position, and saturation
• Gestalt principles also help with understanding with relatively little cognitive load
• If tables were accessible, we wouldn't have data visualizations. So we know they're not good enough on their own.
• Demo of accessible data viz tool Fizz Reader

• SEO = strategic changes to websites to increase search engine ranking
• A11y = designing & building websites so anyone can interact regardless of ability.
• Structure: good for search engine bots AND assistive tech users. Using semantic HTML, clear & consistent architecture improve scan-ability for bots and humans alike. (Tip: don’t overuse h1 tags. Search engines will down-rank you if you have too many)
• Links & media: a11y also helps users with low bandwidth & those who view content without sound (i.e., when in public). Descriptive link text, alt text, consistent file naming, all help with SEO as well as a11y.
• Content: include bullets, lists, & white space (preferred by SE bots and people with attention/cognitive disorders) and aim for 9th-grade reading level for copy
• A11y Style Guide available here

• AT is a barrier for seniors accessing technology because it’s expensive & there’s a learning curve
• biggest issues = overestimating what AT can do or underestimating what seniors can do.
• important to understand the emotional component of seniors needing assistive tech. For some it’s traumatic to acquire disability so they are coming to your product already frustrated.
• What makes a good website for an elderly end user? Obvious items include text size, mouse and keyboard use both accounted for, basically WCAG standards
• Seniors like what works, meaning they hate upgrading / updating their tech.
• “Don’t make me hunt down my mouse cursor in a mass of text”
• Consider cognitive load and distractions. Moving elements or pop ups break focus and cause the user to forget what they were doing.
• Use clear error message so when a form can’t be submitted the user knows where the error is and how to fix it
• Personas should consider: various short term memory lengths, lack of tech knowledge, and the perspectives of real people with disabilities

• ARIA should be used sparingly— “the first rule of ARIA is only use it when you need to”
• when AJAX first started being used JAWS and other screen readers didn’t look for updates after page load, so pages built with AJAX presented a problem
• the idea that screen readers are to blame when they don’t work with HTML5 is a myth. Remember that many new HTML5 standards not yet implemented for browsers.
• Steve has created a github repo so people can file issues for bugs with JAWS / VFO

WheelMap - For Wheelchair Accessible Places

ACCESS MAP - Accessibility in Public Transport Systems

Annotations offer exciting opportunities in the area of accessibility.

These interventions include complying with Level AA Success Criteria set out by the W3C in the Web Content Accessibility Guidelines (WCAG) 2.0.

test

Interesting idea to incorporate the interview content in three ways. Those who want to use it as an article can do so, and those who want the original source can still access it.

Just a note to say that we are using this page for accessibility testing.

It may be wise for a DH scholar to write an article geared towards undergraduates. Similar to the way this article is written, perhaps the use of memes and "slang" could create a more accessible (and interesting) way for undergraduates to understand digital humanities.

So many challenges here, and we really must address all of them. I'm also interested in learning how to make sure my websites and other affordances I use are accessible to people with disabilities.

Good rationale for not enacting a blanket classroom tech ban

accessibility over compliance. Love it.

Note: this should be independent of screen reader function. People who are sighted but have mobility difficulties need to be able to make and access highlights using their keyboard.

This is something we could work on and contribute back to the W3C community

not always considered in matters of accessibility, but important

Can, but doesn't have to - in fact online highlighting can be EASIER for people with certain disabilities

Broader concept of access to education.

Is there an appetite for an app perhaps? EndNote has one, and I use t a lot as part of my digital workflow as I move from phone to tablet, and sometimes desktop. It seems to me that to tether us to a desktop (even if it is a laptop) is becoming somewhat anachronistic these days.

I'm also curious about how accessible hypothes.is is. Can you comment on that? I mean from a WCAG perspective.

ugh. here link

@kgoin Conference

Accissible Syllabus

Parallels to OER and Open Ed

Feature for navigating through landmarks in a page specifically.

This appears to be the closest available functionality in Windows 10 Narrator to the Web item rotor

Excellent website accessibility tester resource. http://www.chronicle.com/blogs/profhacker/use-wave-tool-to-test-web-pages-for-accessibility/63744

This is super cool!

I know we're not supposed to say "I disagree," so I'll try to go about this a bit more cautiously. This line of thinking is, I think, one of the more pervasive misconceptions about composition still today. When considering accessibility options, a lot of people with disabilities are often told, "Just get some dictation software." But this very rarely does what people need it to do, not just because of the editing difficulty, but because the ways we talk (and listen) are often just too different than the ways we write (and read).

Perhaps Muckelbauer's dilemma here is rooted in the fact he is a bad rhetorician.

The inability to craft an accessible definition or understanding of rhetoric for those who are not engaged with field is, in my opinion, bad rhetoric. Can rhetoric be justified if rhetoricians are unable to craft effective rhetoric to explain it?

While offering a single answer to this question may appearing limiting, a basic study of rhetoric will tell you that the single answer is necessary as that is the rhetorical form that is demanded.

I'm commenting here because the ticket is closed (and consequently locked), but we do have an accessibility report from August 2016 focused only on the client at https://docs.google.com/document/d/1aV4yOqR-rbBjy0t4z3cbmDfz4zKmJMt_YEXjYthGODQ/edit?ts=5745a68c

Free as in (neoliberal) speech.

On the one hand, of course. On the other...default accessibility it both difficult and can cut down on the type of "fun" and or "engaging" applications you might use.

Could see a lot of potential for Open Standards, including annotations. What’s not so clear is how they can manage to produce such ePub while maintaining their DRM-focused practice. Heard about LCP (Lightweight Content Protection). But have yet to get a fully-accessible ePub which is also DRMed in such a way.

Aren't we putting OER out there assuming that others will adapt the material to their needs?

Useful suggestion for using a combination of px, rem and em sizing for different elements of a page/app.

Useful article on pros/cons of em vs. px with current browsers.

This is good guidance on when/whether to use em vs. px sizing

Useful article giving an overview of the history of how browser zooming affected CSS units.

Makes a strong overall recommendation to use px almost everywhere, except where component size elements should specifically relate to their font.

This is a useful resource on the history of zooming and accessibility in browsers.

See also this argument

This looks like a lot of manual work for web authors that many are likely to get wrong. How much of this could be automated?

There's a relationship here between the method & accessibility practices, right?

Sites like Medium do as well. We may wish to consider that.

Nice point.