Shift Left - Require Right WRT A11yTC 2023-07-31.pptx

Shift Left,
Require Right
Maximizing requirements to minimize
accessibility issues
Slides: TBD
July 31, 2023, A11y Twin Cities Meetup – Bill Tyler

2
© 2023 Optum, Inc. All rights reserved. 2
© 2023 Optum, Inc. All rights reserved.
Introductions and agenda
Bill Tyler
Principal Digital Accessibility Engineer
e-mail: btyler@optum.com
linkedin.com/in/billtyler/
Welcome and introduction 5 minutes
Shift Left, Require Right overview 5 minutes
Pillar 1: Testing 25 minutes
Pillar 2: Standardizing 5 minutes
Pillar 3: Communicating (DIY Toolkit) 20 minutes
Questions & Answers Remaining time

3
Shift left.
Require right?

4
Shift Left
“Designing-in” accessibility early in the process
• Add accessibility requirements to documentation
• Reduce rework later when it’s more costly
Overall
• Mostly guidelines, training and simple tools to document a11y
• General approaches
• Cover some accessibility concerns
Typically missing
• Testing using team’s accessibility checklist
• Application to any/all documentation
• Reproducibility
• Maximization of requirements
• Reusable accessibility annotations and documentation
• Guidance for all roles

5
Require Right
Two meanings:
Requirements move “right” – meaning
“forward” in the lifecycle
Getting the requirements “right” – meaning
“complete,” “maximized,” and reproducible
Requiring right provides more ways to reduce risk

6
The 3 pillars
TESTING STANDARDIZING COMMUNICATING

7
Testing
Pillar 1

8
Pillar 1: Testing
Most accessibility “testing” is applied to actual products (websites, apps)
Shifting left can also mean shifting testing left
The goal is to evaluate final checkpoints – where practical – to early design documents
1. Now: Find and correct existing issues already in the requirements
2. Later: Add missing requirements to reduce introducing new issues

9
Use your checklist
Standardizes the process
Tailors it directly to your team and your standards
Makes it reproduceable and potentially measurable
Leverages investment and resources in existing checklist
• One set of standards across the entire process
Not a lighter or inconsistent guidelines when shifting left
• Standardizes of a11y requirements expected in documents used
• Provides basis for a DIY a11y playbook or template for design roles

10
How?

11
Testing existing products is clear and obvious
All checkpoints may apply and must be documented
If not applicable, document and on to next checkpoint
If it applies, test, evaluate and report findings
Findings are put into standard reports such as VPATs

12
“Future” product has only design deliverables
Documents vary in
• Focus
• Scale and scope of work
• Type (such as text vs. graphics)
• Fidelity
Examples
• Project initiation (RFP – request for
proposals)
• A single feature (user story)
• General approach (design pattern)
• Basic presentation (style guide)
• Rough structure of pages
(wireframes)
• Final look of graphics and layout
(design comp)
• Taxonomy or dictionary of terms used
(content guidelines)

13
Basic decision tree (flow chart) of 5 top-level questions
0. Intake document?
1. Applicable to the type of design document?
2. Applicable to the final product?
3. Are testable checkpoint requirements defined in the document?
4. Could testable checkpoint requirements be defined in the document?
Optimize process to identify sub-trees to avoid testing inappropriate checkpoints for each
question

14
Intake Documents
Question 0

15
Question 0: Intake documents
RFP are all general requirements and goals of future product/feature
• There is little or nothing that can be tested
It is possible to identify gaps in overall requirements and budget
• Features to implement
• Budget required
• Requirements and expectations
Examples include
• Infrastructure requirements (site search, multiple language support)
• Procurement or infrastructure implications (third party component libraries)
• Platform support (mobile, responsive design)
• Non-web page requirements (video, audio, PDFs)

16
Shift left to intake documents
Can educate product owners and leadership on their impact on accessibility
Identify and quantify some accessibility risks in initial planning
Allow adjustment and prioritization if needed
Helps confirm accessibility support is a requirement in vendor selections
Helpful in sizing future accessibility testing required

17
11 Sample intake questions topics (WCAG order)
1. IN1.1 Complex images
2. IN1.2 Video / audio
3. IN1.3.1 Data tables
4. IN1.3.2 Alternate content
5. IN1.3.4 Responsive design / mobile support
6. IN2.2 Authentication
7. IN2.4 Site search
8. IN3.1 Multiple language support
9. IN3.3 Forms
10.IN4.1.1 Code validation
11.IN4.1.2 Custom components

18
IN1.1 Complex images
Are there any data visualizations (charts, graphs, data plots), CAPTCHA or other graphics
used for testing?
• If “yes”
If using CAPTCHA (or similar technology), has accessibility included as part of product
requirements?
If using data visualizations or graphics/illustrations for testing, have their accessibility
included as part of product requirements?

19
IN1.2 Video / audio
Does the site have video or audio content?
• If “yes”
Which types?
– Recorded Videos
– Live videos
– Audio-only (podcasts)
– Animations
Do the media (video and audio) deliverables include:
– Captions?
– Transcripts?
– Descriptive audio?
– Live sign language translation?
Is media player accessibility included as part of vendor requirements?

20
IN1.3 Alternate content
Does the site use non-web page content (such PDFs, MS Office files, emails, text
messaging, or ASCII text)?
• If “yes”
If using PDFs, has their accessibility included as part of scope of work?
If using (text or HTML) emails or other non-ASCII documents, has their accessibility
included as part of scope of work?
If downloading spreadsheets, rich text documents, slide presentations, has accessibility
review included as part of preparation and review?

21
IN1.3.1 Data tables
Does the site have major tabular data presentations?
• If “yes”
Are the tables large or complex?
Can they be refactored or simplified?

22
IN1.3.4 Responsive design / mobile support
Is the site designed to support multiple device types?
(phones, tablets, laptops and desktops)
• If “yes”
Will the site use using responsive design?
Will the site use any mobile gestures or motions?
Will it be restricted to single orientation?

23
IN2.2 Authentication
Does the site have authentication and session timeout?
• If “yes”
Will users be told this?
Could it be eliminated or extended?
Will they see a warning before they’re logged out?
If so, how long will they have?
Is the ability to extend the session (prior to timing out) included as a requirement?
Is the session timeout infrastructure known to be accessible?

24
IN2.4 Site search
Does the site have search?
• If “yes”
Is the search engine technology known to be accessible?
• If “no”
Is the site very small (< 20 total pages)?
Are navigation options (other than search) included in the requirements?

25
IN3.1 Multiple language support
Does the site support more than one language?
• If “yes”
Which languages?
Any right-to-left languages (such as Arabic or Hebrew)?
Does the site infrastructure provide full support for multiple languages?
Are language experts available to proofread the results?

26
IN3.3 Forms
Does the site have data entry forms?
• If “yes”
Do they lead to purchases or legal commitments?
Do they include entry or updating of personal information?
Are the forms lengthy, multi-part or complex?
How complete will error detection be? Are there any restrictions?

27
IN4.1.1 Code validation
Does the development team include code validation as part of the implementation and
testing process?
• If “NO”
Is the development team willing to complete training and incorporate it?
Sidebar: SC4.1.1 Parsing
• Code validation is a “shift left” tool
• Why risk not finding bad code that could cause accessibility issues?

28
IN4.1.2 Custom components
Does the site use custom components or dynamic updates (such as single-page apps)?
• If “yes”
Will it use existing component libraries?
If so, are they already known to be accessible?
If not, has accessibility included as part of product requirements?

29
Design Documents
Questions 1 - 4

30
4 design deliverable questions
Four questions to ask of common groups of checkpoints:
1. Applicable to the type of design document?
– If not, next group
2. Applicable to final product?
– If not, next group
3. Are checkpoint requirements already defined in the document?
– If so, test them and report the results – and fix now
4. Could (some, or all?, of the) checkpoint requirements be defined in the document?
– If so, suggest adding what can defined now to reduce risk
Should require only one pass for each document type
Through practice, evaluation should accelerate – think Agile retrospectives

31
Is the grouping applicable
to the type of design
document?
Question 1

32
Not all groupings will apply to all document types
Examples where checkpoints groups probably do not apply:
• Audio and video content typically in high level requirements but treated as final
content and copy
• Style guides unlikely to define keyboard operation
• Web documentation unlikely to get into structure of PDFs or video content
• Low fidelity wireframes typically do not define colors, final layout, copy, or
presentation
• Visual design documents don’t usually include final copy

33
8 Sample design document applicability groupings (WCAG Order)
1. DD1.1 Presentation
2. DD1.2 Video / audio
3. DD1.3 Alternate content
4. DD2.1 User interactions
5. DD2.4 Core features
6. DD2.4.6 Semantic structure and layout
7. DD3.1 Final content
8. DD3.3 Forms

34
Design document applicability grouping questions: 1 of 2
DD1.1 Presentation
• Does this type of document typically define page layout, information or site
presentation?
• Does this type of document typically define graphic or non-text content elements
(such as icons, charts, graphs, photos)?
DD1.2 Video / audio
• Does this type of document typically define use of video, audio or animation content?
DD1.3 Alternate content
• Does this type of document typically define non-web page content (such PDFs, MS
Office files, email, text messages, or ASCII text)?

35
Design document applicability grouping questions: 2 of 2
DD2.1 User interactions
• Does this type of document typically define user interface interactions?
DD2.4 Core features
• Does this type of document typically define core functionality (like navigation, search,
mobile support)?
DD2.4.6 Semantic structure and layout
• Does this type of document typically define site page or content semantic structure or
layout?
DD3.1 Final content
• Does this type of document typically define final copy?
DD3.3 Forms
• Does this type of document typically define data entry or error recovery?

36
Is it applicable to the
final product?
Question 2

37
Applicable to final product?
Does it apply to the final product itself?
• It may be applicable to document type but not the project defined in it
Identify “not applicable” checkpoints in final a11y testing
• It might still be in the product, but covered in a different document
Example of distinctions between questions 1 and 2:
VIDEO / AUDIO
Question 1: Does this type of document typically define use of video, audio or animation
content?
Question 2: Are any videos, audio clips (like podcasts) or animations shown or
mentioned in the document as part of the product?

38
8 Sample product applicability groupings (in WCAG order)
1. AP1.1 Presentation
2. AP1.2 Video / audio
3. AP1.3 Alternate content
4. AP2.1 User interactions
5. AP2.4 Core features
6. AP2.4.6 Semantic structure and layout
7. AP3.1 Final content
8. AP3.3 Forms
Indexes map to document type

39
Product applicability questions: 1 of 3
AP1.1 Presentation
• Are graphics or non-text content elements (of any kind) shown or mentioned in the
document as part of the product?
• Is the (final) site presentation (such as foreground and background colors) shown or
mentioned in the document as part of the product?
AP1.2 Video / audio
• Are any videos, audio clips (like podcasts) or animations shown or mentioned in the
document as part of the product?
• Has the accessibility of the media player been confirmed?

40
AP1.3 Alternate content
• Is any non-web page content (such PDFs, MS Office files, emails, text messages, or
ASCII text) shown or mentioned in the document as part of the product?
AP2.1 User interactions
• Are user interfaces elements or interactions shown or mentioned in the document as
part of the product?
AP2.4 Core features
• Is core site functionality shown or mentioned in the document as part of the product?
• Are any requirements defining mobile device operation, such as single orientation,
gestures, or motion?

41
AP2.4.6 Semantic structure and layout
• Is page or content semantic structure or layout shown or mentioned in the document
as part of the product?
• Are data tables shown or mentioned in the document as part of the product?
AP3.1 Final content
• Is any (final) site content shown or mentioned in the document as part of the
product?
AP3.3 Forms
• Are any data entry forms shown or mentioned in the document as part of the
product?

42
Testing document
accessibility and
suggestions
Question 3 and 4

43
Question 3 and 4 work together
Question 3: Are there enough requirements defined to meaningfully test the actual
checkpoint?
Examples: Final text colors, semantic structures, focus order
• If so, test the checkpoint(s) and report findings
• If some – but not all – requirements found, note “gap” for question 4
Question 4: Could we do “more” meaningful testing in the document?
• For gaps, identify missing requirements fill them in future testing
• Look for full omissions as new opportunities
NOTE: Checkpoint applicability will vary based upon document type, product and level of
document detail

44
Shifted-left checkpoint
testing examples

45
Wireframe: defines tabular data presentation
Q3 – Data tables defined
• Obvious (implicit) column headers
Q4 – Missing requirements and definitions
• Explicitly define column headers
• Define row headers
• Define caption or table name

46
Style guide: defines approved brand colors for content
Q3 – Foreground and background colors defined
• Can test some combinations
Q4 – Approved combinations or applications?
• Ensure contrast by defining approved combinations
• Contrast levels
– Text
– Icons and graphics
– Visible focus
– Data visualizations
• Stay on brand when accessible

47
Style guide: defines approved colors for interactions
Q3 – Hover presentation defined
• No visible focus
Q4 – Require visible focus design
• Add visible focus states
• Define for all current elements
• Provide guidance for future elements
• Design to keep on brand

48
Wireframe: defines page layout
Q3 – Some basic page structure defined
• Page header
• Page footer
• Main navigation
• Main content and variations
Q4 – Missing semantic structures and definition
• Identify other major sections asides, blockquotes, articles, sections
• Headings: specify semantic – not visual – heading levels for proper nesting

49
Design comp: presents data visualization or complex graphic
Q3 – Contrast and visual accessibility
• Avoid only use of color
• Non-text contrast
Q4 – Clear definition and description of key information
• Data tables
• Meaningful text descriptions
• Accessible interactivity

50
User story: defines new component operation
Q3 – Mouse and touchscreen operation and visual presentation defined
• General operation and patterns
• Some keyboard operation for text entry
Q4 – Add missing requirements where appropriate
• Define missing keyboard operation and support, using WAI-ARIA if possible
• Define missing names, roles, values and statuses to announce

51
Benefits and limitations
Hard failures are guaranteed, conformance is not
• An inaccessible decision guarantees failure
• Providing requirements reduces that risk
• Accessibility requirements are no different from those for features and designs
Shifting accessibility testing left to developers and QA testers
• Defining accessibility requirements makes it possible to shift (some) accessibility
testing left
• Developers should be able to do basic keyboard testing while implementing design
requirements (and validating code)
• QA testers should be able to do that and confirm the design matches the
requirements

52
Standardizing
Pillar 2

53
Pillar 2: Standardization
Standardization can be built upon the results testing and analysis
Results from questions 1, 3 and 4 can define a standard set of (applicable) checkpoints
and accessibility requirements for that document type
• Can start using documents from previous projects
• Can be done as exercise on an abstract document type or case
which may be necessary to ensure coverage of less common checkpoints
Adding question 2 can help create a playbook for creating design documents for a project
• Prepare document authors to address the checkpoints
• Lean how to write and confirm accessibility requirements
• Can provide guidance all roles might learn and apply

54
Pillar 2: Standardization (continued)
Using your left-shifted checkpoints should provide 1-to-1 correspondence between the
requirements in design documents to actual testing results
Retrospective review can indicate checkpoints that were missed or need better
documentation
Refinements can improve results in future projects
The results should be measurable, including areas needing more accessibility input

55
Communicating
Pillar 3

56
Accessibility documentation and annotations (or badges)
With standardized a11y requirements comes the need
to document them in a standard way
Varying document types can make this difficult
(graphic vs. text)
Some toolkits already exist for many tools (especially
visual design, such as Figma, Miro, Sketch)

57
Common limitations of a11y toolkits: Breadth
Most are limited to a small number of web concepts (headings, buttons, links, focus order)
Large count, minor differences
• 4-point orientation (same box, 4 different pointers)
• Minor text differences
• Different colors
Often not scannable
• Require additional (“numbered”) footnotes to document additional details
• Often are specific to that instance with limited reusability
Focused mainly on web/HTML concepts
• Not mobile (iOS, iPadOS, Android)

58
Common limitations of toolkits: Depth
Can be overly prescriptive
• May defines <img> when <svg> will be used
• May define HTML approaches when WAI-ARIA must be used
Little or no supporting documentation for the toolkit
• Mainly document simple, small UI elements not sections/regions
Have little or no supporting documentation for the project team
• To supplement the annotations in design tools
• To share and reuse across projects

59
A glimpse into our annotation system (work in progress)
Sorry.
Currently internal use only

60
Our A11y badge kit: History
Originally built in Miro
Ported to
• Sketch
• Visio
• Figma
Built to support
• Web
• iOS
• iPadOS
• Android

61
Our A11y badge kit: Scale and scope
121 different annotations in 10 sets
• Page templates (6)
• Navigation (8)
• Semantics and content (12 web, 6 mobile)
• Data tables and data grids (8)
• Images (4)
• Forms, fields, labels, instructions and errors (29)
• Autofill (14)
• ARIA roles and state attributes (7)
• WAI-ARIA components (17)
• Mobile device concepts (10)

62
Conventions used to improve communication
Stacking badges to document multiple requirements for a single element – for reusability
Grouping, nesting and area definition through brackets
Use of lines to reduce overlap
Additional support
• Comments
• Focus order
• Design issues and errors
• Documentation (next slide)

63
Expanded documentation
3 levels of documentation
• Badge – immediate in design document
• QuickRef – basic details also in document
• Full documentation – more comprehensive external reference
Support multiple roles
• Visual design
• User experience and interaction design
• Content authoring
• Development

64
Guidelines to
do it yourself
Quickly, easily, based upon many lessons learned

65
DIY: Creating and maximizing your own annotation system is not hard
Most annotation badges are easy to create
• Mostly picking existing shapes and colors then adding text
What is helpful is making them more powerful and complete
• Broader: more concepts and requirements
• Deeper: more details and (reusable) information
Build what you need to make sure can document all your requirements
Some design guidance based on experience should help you build your own
• If necessary, get an expert (UX designer?) to help get you started

66
A11y badge design guidelines: Initial selections
For simplicity, keep to single color
• SC1.4.1 Use of Color (Level A)
• Content reviewers learn that “color” means “accessibility” (and…)
• Choose a generic color typically found in most tools
Use simple shape(s) as base badge elements
• SC1.4.1 Use of Color (Level A) applied
• Create a single shape for badge documentation
• Content reviewers learn that “shape” means “accessibility”
• Create only 1 generic shape not sets of 4
• Choose a shape typically found in most tools

67
A11y badge design guidelines: Keep things simple
Keep core badge types (concepts) distinct
• Core badges for topics should be visually distinct from those used for focus order, error or
notes
• Example:
– Elements: white text on purple diamonds
– Comments: purple numbers on white diamonds with purple outline
– Focus order: white numbers on purple circles
Use lines to “connect” badges to design elements
• Lines are common in all design tools
• Easier and faster to create (and maintain) 1 –not 4 badges – at time
• Universal badge with no concern about correct pointer
• Reduces clutter and unwanted overlap

68
A11y badge design guidelines: Creating element names
Keep concepts focused and discrete for maximum reuse
• Avoid “complex” badges like “text field required autocomplete first name”
• Split into simpler, more reusable items to group “visually”
Example
– Text Field
– Required
– Autocomplete first name
Use short, descriptive acronyms (not HTML) in badges
• Make acronyms understandable to broader audiences (“BuL” - bulleted list not <ul>)
• Make them scannable and memorable to be learned quickly
• Do not assume implementation (HTML, WAI-ARIA, mobile)
• Custom acronyms can become excellent key words in searches

69
A11y badge design guidelines: Build a reusable asset library
Make badges a common asset library
• A single kit shared across projects, not copied
• Allow easier maintenance with faster updates from single source
Where possible, group badges in logical topics
• Big libraries can make finding individual badges difficult
• Groupings provide faster access as library grows
Example: Figma Assets library
• Frames allow create groupings by topic
• Results are automatically alphabetized

70
A11y badge design guidelines: Create supporting documentation
Support documentation
• Create and update separate documentation for all badges
• Keep it simple, start with a simple Word or text document
• Migrate to internal product support resources when appropriate
Write documentation broadly and deeply
• Provide details for need all roles involved in decisions
– Visual designers, UX designers, content authors and developers
• Cover key accessibility requirements
• Provide appropriate links to internal and external resources
• Include recommended implementation details where applicable

71
A11y badge design guidelines: Support different documentation
approaches
Build quick reference aids to use in visual tools
• Provides immediate documentation by badges
• Cover high-level details for key audiences
• Include basic implementation details for developers
• Quick reference elements can be another library
Create text alternative for non-visual documents
• Avoid simple < and > that may be confused with HTML
Example “BuL” for bulleted list
Use [ BuL ] generic text
not <BuL> that might be confused as actual HTML

72
Use same badge style in different document types and tools
Style guide (Miro), wireframe (Visio), page comp (Figma) and component (Figma)

73
Examples, examples,
examples

74
Example: Simple text field
A simple field for entering an optional favorite food using a standard text input would use lines to
connect badges to screen elements (in this and all examples).
[ Lbl ] indicates the text “Favorite food (optional)” labels the field box
[ TxF ] indicates the box is a simple text field

75
Example: Simple checkbox field
An optional checkbox for requesting to “Email latest updates”.
[ Ckb ] indicates the checkbox field box with line to the checkbox element
[ Lbl ] indicates the text “Email latest updates” labels the checkbox

76
Example: Radio button grouping
A required gender selection grouping with four radio button options “Male,” “Female,” “Non-binary,”
and “Prefer not to say.”
[ RqF ] used to indicate a required field stacked on
[ FGr ] uses a bracket to identity the contents of the grouping
[ Lgd ] provides a name (legend) for the group at to the of the grouping
[ Rdo ] identifies the clickable option radio button circles with
[ Lbl ] providing text labeling for each button

77
Example: Required city field
A required city data entry field
[ Lbl ] indicating the text “* City” is the label for the field
[ RqF ] indicating the field should be programmatically required
[ ACty ] indicating the field should autocomplete the user’s city
[ TxF ] indicating this is simple text field

78
Example: Field with errors
A required email address entry field with no value and error message
[ Lbl ] indicating the text “* Email address” for the field
[ ErS ] indicating the field should be programmatically indicated as having an error state (invalid)
[ RqF ] indicating the field must be marked programmatically required
[ AEm ] indicating the field should autocomplete the user’s email addressed
[ EmF ] for the email field (box)
[ ErM ] indicating the text “enter using format name@domain.com” is a programmatically related error
message for the field

79
Design intent detailed example: Mobile app “action card”
This is a non-trivial example of a mobile application element which has three different
groups of related information (including heading) to be communicated in separate swipes:
• Two distinctly different button actions
• A small, and somewhat unobvious “data visualization”

80
Example: Complex mobile design “action card” – Part 1
[ Dec ] indicates the orange gradient card background (including the “fork and spoon”) is
decorative and should not be announced
[ Img ] & [ CtHB ] stacked
• [ Img ] indicates the “fork and spoon” icon is informational content with a text alternative
that defines a “category”
• [ CtHB ] the main text on the top of the button “Choose keto-friendly snacks” is a
“Category header button” (a custom element created for the mobile app).
• This also provides context for the rest of the card’s content
(1) Together the icon and text represent a swipe, grouping, announcement and tap target

81
Example: Complex mobile design “action card”
[ Btn ] on the top right indicates the black text “I did it” in a white roundtangle is a simple
button
[ Cpl ] indicates the “7 light orange segments in a bar graph” towards the bottom the card
is a complex image with a text alternative
(2) – (3) connect to boxes showing the individual sections of groupings of information in
swipe order

82
Defining screen reader announcements: Content Heading Button
(1) [ Img ] [ CtHB ] – The first swipe grouping has text to the left side that describes how
this element should announce.
The “How ‘Action Card Headings’ should announce:” with the sample expected
announcement below “Nutrition: Choose keto-friendly snacks, Heading, Button”

83
Button and graphic announcement
(2) [ Btn ] – The second swipe grouping has text to the right side describing how the
simple text button in this state should be announced.
Top line is the instruction “Selecting/Toggling should announce:” with the sample expected
announcement below “I did it, Button”
(3) [ CpI ] – The third swipe grouping has text to the right side describing how the simple
text button in this state should be announced
Top line is the instruction “How “Action Card day segments (with results)” should
announce:
with expected sample announcement below of “Completed zero times in the past seven
days”

84
State changes
(2) [ Dec ] – The “I did it” button presentation inverts to white on black with decorative
white checkmark icon followed by “Done”
Top line is the instruction “Selecting/Toggling should announce:” with the sample expected
announcement below “Done, Button”
(3) [ CpI ] – The complex image shows the right-most segment changed from light orange
to white – to indicate it was done “today” on the right end. has text to the right side
describing how the simple text button in this state should be announced
Top line is the instruction “How ‘Action Card day segments (with results)’ should
announce:”
with sample announcements below of “Completed one time in the past seven days” and
“Completed seven times in the past seven days”

85
Altogether, it’s not too complicated
Here’s a more realistic view of how everything comes together in a final design.
The initial state covers all the basics
The updated state covers only the changes and details involved

86
Questions & Answers
Q&A

87
Thank you.

Optum is a registered trademark of Optum, Inc. in the U.S. and other jurisdictions. All other brand or product names
are the property of their respective owners. Because we are continuously improving our products and services,
Optum reserves the right to change specifications without prior notice. Optum is an equal opportunity employer.
Optum is a registered trademark of Optum, Inc. in the U.S. and other jurisdictions. All other brand or product names
are the property of their respective owners. Because we are continuously improving our products and services,
Optum reserves the right to change specifications without prior notice. Optum is an equal opportunity employer.

Shift Left - Require Right WRT A11yTC 2023-07-31.pptx

Recommended

Recommended

More Related Content

Similar to Shift Left - Require Right WRT A11yTC 2023-07-31.pptx

Similar to Shift Left - Require Right WRT A11yTC 2023-07-31.pptx (20)

More from Bill Tyler

More from Bill Tyler (12)

Recently uploaded

Recently uploaded (20)

Shift Left - Require Right WRT A11yTC 2023-07-31.pptx