Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Accessible
modal
windows
What is a modal
window?
A modal window is a window
that forces the user to interact
with it before they can go back to
using the parent page.
Generally, modal windows are
designed to sit over the top of
the parent page. In some cases,
the parent page is greyed out...
Different types of
modal window
Modal windows can be used for
all sorts of different roles such
as:
Modal alerts
Modal dialogs
Modal lightboxes
Modeless windows
Modal windows should not be
mistaken for modeless windows.
Modeless windows are secondary
windows that stay active on the
user's screen until dismissed.
Modeless windows can be
mini...
Unlike a modal window, a
modeless window will allow the
user to continue working with
the application while the modeless
w...
What makes an
accessible modal
window?
Keyboard only
Users must be able to navigate
through the modal window as
needed using keyboard-only.
Users should be able to close the
modal window using keyboard-
only.
Users should not be able to TAB
outside of the modal window
until the modal window has been
closed.
There should be no hidden
keystrokes as users move through
the modal window.
Screen reader
All relevant components should be
identified to screen reader users
as they are accessed.
Screen readers should be notified
of changes as they occur.
Focus should be placed on
relevant areas as changes occur.
General user
The process should be easy to
understand for any type of user -
keyboard only user, screen reader
user, general user.
Informing users
before modal
window spawning
If a modal window spawns from a
focusable element, screen reader
users should be given additional
information to let them ...
This can be done using a range of
different methods, depending on
the element that is used.
Hyperlinks
For hyperlinks, we could add
additional information using the
“title”, aria-labelledby, or “aria-
label” attributes. Or we...
<!-- title attribute -->!
<a href="#id-name" !
! title="Added info">!
! Add bank account!
</a>!
<!-- aria-label attribute -->!
<a href="#id-name" !
! aria-label="Add bank account - Added
info">!
! Add bank account!
</a...
<!-- aria-labelledby attribute -->!
<a href="#id-name" !
! aria-labelledby="info1">!
! Add bank account!
</a>!
<p id="info...
<!-- hidden info -->!
<a href="#id-name">!
! Add bank account!
! <span class="hidden">Added info</span>!
</a>!
Buttons
For <button> elements, we
could use any of these same
techniques.
<!-- title attribute -->!
<button id="id-name" !
! title="Added info">!
! Add bank account!
</button>!
<!-- aria-label attribute -->!
<button id="id-name" !
! aria-label="Add bank account - Added
info">!
! Add bank account!
<...
<!-- aria-labelledby attribute -->!
<button id="id-name" !
! aria-labelledby="info1">!
! Add bank account!
</button>!
<p i...
<!-- hidden info -->!
<button id="id-name">!
! Add bank account!
! <span class="hidden">Added info</span>!
</button>!
Inputs
For <input> elements, we could
use any of these same techniques -
except the hidden method as we
cannot place HTML markup ...
Images
For <img> elements, we could
use any of the above techniques or
even add info into the “alt”
attribute.
<!-- alt attribute -->!
<a href="#id-name">!
! <img src="a.gif" !
! alt="Add bank account - Added info">!
</a>!
Hiding and
showing modal
windows
1. Hiding the modal
window
Initially, we need to hide the
modal dialog content so that is
not seen by sighted users or heard
by screen reader users.
<!-- hiding modal window -->!
<div!
! style="display:none">!
! ...!
</div>!
2. Showing the modal
window
When a user triggers the modal
window, we need to use
JavaScript to switch the values
within these two attributes.
The “display” value needs to
change from “none” to “block”.
<!-- aria-hidden -->!
<div!
! style="display:block">!
! ...!
</div>!
When the modal window becomes
active, the rest of the page -
everything apart from the modal
window container, could then ...
<!-- all other content -->!
<div!
! aria-hidden="true">!
! ...!
</div>!
!
<!-- modal window -->!
<div!
! style="display:bl...
Notifying screen
readers when
arriving at modal
window
When a modal window is
spawned, we need to provide a
range of information to screen
reader users.
1. Setting focus on the
modal window
The first thing we need to do
when a modal window spawns is
set the initial focus to the modal
window element itself.
Initial focus
This is important because we are
going to give the window a label
as well as potentially adding
additional descriptive inf...
If we set focus on an element
inside the window, such as the
first form control, the label and
additional information will...
Initial focus
2. Add“dialog”role
We need to inform screen reader
users that this modal window is a
“modal dialog”. We can do this by
adding role=“dialog”.
<!-- adding aria role -->!
<div!
! style="display:block"!
! aria-hidden="false"!
! role="dialog">!
! ...!
</div>
3. Adding a label
We need to provide a label for
the modal dialog, so screen
reader users know its purpose.
We can do this by linking the
modal dialog container to the
primary <hn> element using
“aria-labeledby”.
<!-- adding aria labelledby -->!
<div!
! style="display:block"!
! aria-hidden="false"!
! role="dialog"!
! aria-labelledby=...
Now the heading will be
announced to screen reader
users when the modal dialog is
spawned.
4. Adding optional
additional information
In some circumstances, such as
complex modal dialogs, we may
need to provide a more detailed
description of the purpose of...
We can provide additional
information by linking the modal
dialog container to some
descriptive content using “aria-
descr...
<!-- adding aria labelledby -->!
<div!
! style="display:block"!
! aria-hidden="false"!
! role="dialog"!
! aria-labelledby=...
Ideally, this content should be
hidden or placed at the end of
the modal dialog content, after
all other content in the so...
Otherwise it can be read-aloud
twice in quick succession by
screen readers, which can be
confusing for some users.
5. Working with older
Assistive Technologies?
What about older assistive
technologies that may not
support some of the more
advanced ARIA attributes?
If this is an issue, other simpler
options may need to be
considered.
One simple option would be to
provide a special focusable
element, such as a link, that
comes before all others.
This could be presented as a
simple “Information” icon that
sits in the top left corner of the
window.
We could then add a description
of the modal window to this link.
<!-- help info -->!
<a href="#id-name">!
! <img src="a.gif" alt="Help">!
! <span class="tooltip">Added info</span>!
</a>!
!
This method could be useful for
both screen reader users and
general users, as the information
could be made visible as a
...
Actions outside
the modal window
Users should not be able to
mouse-click on any focusable
element outside the modal
window while it is open.
CLICK
Users should not be able to use
TAB keystrokes to focus on any
focusable element outside the
modal window while it is open.
TAB
Actions inside
modal window
Mouse
Users should be able to mouse-
click to enable any focusable
element inside the modal window
while it is open.
CLICK
CLICK
CLICK
CLICK
CLICK
CLICK
CLICK
TAB keystroke
Users should be able to use TAB
keystrokes to navigate to any
focusable element inside the
modal window while it is open.
TAB
TAB
TAB
TAB
TAB
TAB
TAB
SHIFT + TAB keystroke
Users should be able to use
SHIFT + TAB keystrokes to
navigate backwards to any
focusable element inside the
modal window ...
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
ENTER and SPACE
keystrokes
Users should be able to use
ENTER or SPACE keystrokes on
relevant elements while inside the
modal window - especially if t...
ENTER
ENTER
SPACE
SPACE
ARROW keystrokes
When inside form controls,
ARROW keys are generally used to
allow users to navigate user-
entered text within the form
con...
An example might be a user
entering data into a <textarea>
element. The user can navigate
within their entered text using
...
However, some form controls use
ARROW keys to allow users to
choose options within a set of
choices.
For example, radio buttons and
select menus allow users to
navigate through choices using
ARROW keys.
So, users should be able to use
ARROW keystrokes to change
radio button options.
TAB
ARROW
Users should be able to use
ARROW keystrokes to change
select menu options.
Option 1 - apples
ARROW
Option 2 - pears
ARROW
Option 3 - bananas
ARROW
ESC keystroke
Users should be able to use the
ESC key to close modal.
ESC
Modal windows
and screen reader
“read” mode
Screen readers generally operate
in one of two modes: ‘read’ mode
and ‘form’ mode.
In “read” mode, users can read
and navigate the page. Users
cannot interact with form controls
In “form” mode, users can interact
with form controls. Users cannot
read and navigate the page.
In some cases, modal windows
may include important content
that is not form-related. In these
cases, screen reader users n...
This means that screen reader
users must be able to navigate
though content using all of the
standard “read” mode keys.
In these cases, we could wrap a
new element around all the
content within the window and
set it with role=“document”.
The “document” role informs
screen readers of the need to
augment browser keyboard
support so that users can navigate
and ...
<!-- adding aria role -->!
<div!
! style="display:block"!
! aria-hidden="false"!
! role="dialog"!
! aria-labelledby="modal...
Adding meaning to
important actions
For some important actions inside
the modal window, screen reader
users should be given additional
information to let them...
Submit
As screen reader users are
submitting form data, they
should be informed that:
1. they will be taken back to the
parent page.
2. where this data will be
submitted when they return to
the parent page.
ENTER
“Submit and return to bank
balance information. Your
data will be added to the
Balance table”
Close window
As screen reader users focus on
the “Close” function, they should
be informed that closing will
take them back to the pare...
ENTER
“Leave form and return to
bank balance information”
A question on tab
order
Is it better to present to “Close”
button before any form controls in
tab order, or after any form
controls.
A lot will depend on the
complexity and amount of
content inside the modal window.
Simple modal windows
For simple modal windows, it may
be easier to place the “Close”
button last in tab order.
1
2
3
Complex modal windows
For complex modal windows,
where users may want to go back
to the parent page quickly without
having to TAB through the wh...
1
2
3
4
5
6
On sites where there are
numerous different modal dialogs,
the most important thing is
consistency. Decided on a method
an...
After modal dialog
closes
When the modal window is closed,
if users are being taken back to
the parent page:
1. Focus should be placed on the
relevant component of the parent
page. The most common practice
is to move focus back to ...
The user should not be thrown
back to the top of the parent
page unless there is a good
reason!
2. The user should be informed
where they are and what change
has occurred.
ENTER
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut laoreet dolore magna ali...
Thanks to…
A huge thanks to Roger Hudson,
Steve Faulkner and James
Edwards for their advice and
feedback on these slides.
Russ Weakley
Max Design
!
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
L...
Accessible modal windows
Accessible modal windows
Accessible modal windows
Upcoming SlideShare
Loading in …5
×

Accessible modal windows

7,723 views

Published on

A detailed slideshow on making modal windows accessible

Published in: Education

Accessible modal windows

  1. 1. Accessible modal windows
  2. 2. What is a modal window?
  3. 3. A modal window is a window that forces the user to interact with it before they can go back to using the parent page.
  4. 4. Generally, modal windows are designed to sit over the top of the parent page. In some cases, the parent page is greyed out so that users can visually focus on the modal dialog only.
  5. 5. Different types of modal window
  6. 6. Modal windows can be used for all sorts of different roles such as:
  7. 7. Modal alerts
  8. 8. Modal dialogs
  9. 9. Modal lightboxes
  10. 10. Modeless windows
  11. 11. Modal windows should not be mistaken for modeless windows.
  12. 12. Modeless windows are secondary windows that stay active on the user's screen until dismissed. Modeless windows can be minimised or hidden behind other windows.
  13. 13. Unlike a modal window, a modeless window will allow the user to continue working with the application while the modeless window is still open.
  14. 14. What makes an accessible modal window?
  15. 15. Keyboard only
  16. 16. Users must be able to navigate through the modal window as needed using keyboard-only.
  17. 17. Users should be able to close the modal window using keyboard- only.
  18. 18. Users should not be able to TAB outside of the modal window until the modal window has been closed.
  19. 19. There should be no hidden keystrokes as users move through the modal window.
  20. 20. Screen reader
  21. 21. All relevant components should be identified to screen reader users as they are accessed.
  22. 22. Screen readers should be notified of changes as they occur.
  23. 23. Focus should be placed on relevant areas as changes occur.
  24. 24. General user
  25. 25. The process should be easy to understand for any type of user - keyboard only user, screen reader user, general user.
  26. 26. Informing users before modal window spawning
  27. 27. If a modal window spawns from a focusable element, screen reader users should be given additional information to let them know what will happen.
  28. 28. This can be done using a range of different methods, depending on the element that is used.
  29. 29. Hyperlinks
  30. 30. For hyperlinks, we could add additional information using the “title”, aria-labelledby, or “aria- label” attributes. Or we could place the addition information inside the link and then hide it.
  31. 31. <!-- title attribute -->! <a href="#id-name" ! ! title="Added info">! ! Add bank account! </a>!
  32. 32. <!-- aria-label attribute -->! <a href="#id-name" ! ! aria-label="Add bank account - Added info">! ! Add bank account! </a>!
  33. 33. <!-- aria-labelledby attribute -->! <a href="#id-name" ! ! aria-labelledby="info1">! ! Add bank account! </a>! <p id="info1" class="hidden">! ! Added info! </p>!
  34. 34. <!-- hidden info -->! <a href="#id-name">! ! Add bank account! ! <span class="hidden">Added info</span>! </a>!
  35. 35. Buttons
  36. 36. For <button> elements, we could use any of these same techniques.
  37. 37. <!-- title attribute -->! <button id="id-name" ! ! title="Added info">! ! Add bank account! </button>!
  38. 38. <!-- aria-label attribute -->! <button id="id-name" ! ! aria-label="Add bank account - Added info">! ! Add bank account! </button>!
  39. 39. <!-- aria-labelledby attribute -->! <button id="id-name" ! ! aria-labelledby="info1">! ! Add bank account! </button>! <p id="info1" class="hidden">! ! Added info! </p>!
  40. 40. <!-- hidden info -->! <button id="id-name">! ! Add bank account! ! <span class="hidden">Added info</span>! </button>!
  41. 41. Inputs
  42. 42. For <input> elements, we could use any of these same techniques - except the hidden method as we cannot place HTML markup inside input elements.
  43. 43. Images
  44. 44. For <img> elements, we could use any of the above techniques or even add info into the “alt” attribute.
  45. 45. <!-- alt attribute -->! <a href="#id-name">! ! <img src="a.gif" ! ! alt="Add bank account - Added info">! </a>!
  46. 46. Hiding and showing modal windows
  47. 47. 1. Hiding the modal window
  48. 48. Initially, we need to hide the modal dialog content so that is not seen by sighted users or heard by screen reader users.
  49. 49. <!-- hiding modal window -->! <div! ! style="display:none">! ! ...! </div>!
  50. 50. 2. Showing the modal window
  51. 51. When a user triggers the modal window, we need to use JavaScript to switch the values within these two attributes.
  52. 52. The “display” value needs to change from “none” to “block”.
  53. 53. <!-- aria-hidden -->! <div! ! style="display:block">! ! ...! </div>!
  54. 54. When the modal window becomes active, the rest of the page - everything apart from the modal window container, could then be set with aria-hidden=“true”.
  55. 55. <!-- all other content -->! <div! ! aria-hidden="true">! ! ...! </div>! ! <!-- modal window -->! <div! ! style="display:block">! ! ...! </div>! !
  56. 56. Notifying screen readers when arriving at modal window
  57. 57. When a modal window is spawned, we need to provide a range of information to screen reader users.
  58. 58. 1. Setting focus on the modal window
  59. 59. The first thing we need to do when a modal window spawns is set the initial focus to the modal window element itself.
  60. 60. Initial focus
  61. 61. This is important because we are going to give the window a label as well as potentially adding additional descriptive information.
  62. 62. If we set focus on an element inside the window, such as the first form control, the label and additional information will not be heard by screen reader users.
  63. 63. Initial focus
  64. 64. 2. Add“dialog”role
  65. 65. We need to inform screen reader users that this modal window is a “modal dialog”. We can do this by adding role=“dialog”.
  66. 66. <!-- adding aria role -->! <div! ! style="display:block"! ! aria-hidden="false"! ! role="dialog">! ! ...! </div>
  67. 67. 3. Adding a label
  68. 68. We need to provide a label for the modal dialog, so screen reader users know its purpose.
  69. 69. We can do this by linking the modal dialog container to the primary <hn> element using “aria-labeledby”.
  70. 70. <!-- adding aria labelledby -->! <div! ! style="display:block"! ! aria-hidden="false"! ! role="dialog"! ! aria-labelledby="modal-label">! ! <h1 id="modal-label">! ! ! Choose account! ! </h1>! </div>!
  71. 71. Now the heading will be announced to screen reader users when the modal dialog is spawned.
  72. 72. 4. Adding optional additional information
  73. 73. In some circumstances, such as complex modal dialogs, we may need to provide a more detailed description of the purpose of the modal dialog.
  74. 74. We can provide additional information by linking the modal dialog container to some descriptive content using “aria- describedby”.
  75. 75. <!-- adding aria labelledby -->! <div! ! style="display:block"! ! aria-hidden="false"! ! role="dialog"! ! aria-labelledby="modal-label"! ! aria-describedby="modal-description">! ! <h1 id="modal-label">! ! ! Choose account! ! </h1>! ! <p id="modal-description">! ! ! Description here! ! </p>! </div>!
  76. 76. Ideally, this content should be hidden or placed at the end of the modal dialog content, after all other content in the source.
  77. 77. Otherwise it can be read-aloud twice in quick succession by screen readers, which can be confusing for some users.
  78. 78. 5. Working with older Assistive Technologies?
  79. 79. What about older assistive technologies that may not support some of the more advanced ARIA attributes?
  80. 80. If this is an issue, other simpler options may need to be considered.
  81. 81. One simple option would be to provide a special focusable element, such as a link, that comes before all others.
  82. 82. This could be presented as a simple “Information” icon that sits in the top left corner of the window.
  83. 83. We could then add a description of the modal window to this link.
  84. 84. <!-- help info -->! <a href="#id-name">! ! <img src="a.gif" alt="Help">! ! <span class="tooltip">Added info</span>! </a>! !
  85. 85. This method could be useful for both screen reader users and general users, as the information could be made visible as a tooltip on focus.
  86. 86. Actions outside the modal window
  87. 87. Users should not be able to mouse-click on any focusable element outside the modal window while it is open.
  88. 88. CLICK
  89. 89. Users should not be able to use TAB keystrokes to focus on any focusable element outside the modal window while it is open.
  90. 90. TAB
  91. 91. Actions inside modal window
  92. 92. Mouse
  93. 93. Users should be able to mouse- click to enable any focusable element inside the modal window while it is open.
  94. 94. CLICK
  95. 95. CLICK
  96. 96. CLICK
  97. 97. CLICK
  98. 98. CLICK
  99. 99. CLICK
  100. 100. CLICK
  101. 101. TAB keystroke
  102. 102. Users should be able to use TAB keystrokes to navigate to any focusable element inside the modal window while it is open.
  103. 103. TAB
  104. 104. TAB
  105. 105. TAB
  106. 106. TAB
  107. 107. TAB
  108. 108. TAB
  109. 109. TAB
  110. 110. SHIFT + TAB keystroke
  111. 111. Users should be able to use SHIFT + TAB keystrokes to navigate backwards to any focusable element inside the modal window while it is open.
  112. 112. SHIFT + TAB
  113. 113. SHIFT + TAB
  114. 114. SHIFT + TAB
  115. 115. SHIFT + TAB
  116. 116. SHIFT + TAB
  117. 117. SHIFT + TAB
  118. 118. SHIFT + TAB
  119. 119. ENTER and SPACE keystrokes
  120. 120. Users should be able to use ENTER or SPACE keystrokes on relevant elements while inside the modal window - especially if they are button elements.
  121. 121. ENTER
  122. 122. ENTER
  123. 123. SPACE
  124. 124. SPACE
  125. 125. ARROW keystrokes
  126. 126. When inside form controls, ARROW keys are generally used to allow users to navigate user- entered text within the form control.
  127. 127. An example might be a user entering data into a <textarea> element. The user can navigate within their entered text using ARROW keys to move to previous and next characters, next line etc.
  128. 128. However, some form controls use ARROW keys to allow users to choose options within a set of choices.
  129. 129. For example, radio buttons and select menus allow users to navigate through choices using ARROW keys.
  130. 130. So, users should be able to use ARROW keystrokes to change radio button options.
  131. 131. TAB
  132. 132. ARROW
  133. 133. Users should be able to use ARROW keystrokes to change select menu options.
  134. 134. Option 1 - apples ARROW
  135. 135. Option 2 - pears ARROW
  136. 136. Option 3 - bananas ARROW
  137. 137. ESC keystroke
  138. 138. Users should be able to use the ESC key to close modal.
  139. 139. ESC
  140. 140. Modal windows and screen reader “read” mode
  141. 141. Screen readers generally operate in one of two modes: ‘read’ mode and ‘form’ mode.
  142. 142. In “read” mode, users can read and navigate the page. Users cannot interact with form controls
  143. 143. In “form” mode, users can interact with form controls. Users cannot read and navigate the page.
  144. 144. In some cases, modal windows may include important content that is not form-related. In these cases, screen reader users need to be able to operate in “read” mode.
  145. 145. This means that screen reader users must be able to navigate though content using all of the standard “read” mode keys.
  146. 146. In these cases, we could wrap a new element around all the content within the window and set it with role=“document”.
  147. 147. The “document” role informs screen readers of the need to augment browser keyboard support so that users can navigate and read any content within the “document” region.
  148. 148. <!-- adding aria role -->! <div! ! style="display:block"! ! aria-hidden="false"! ! role="dialog"! ! aria-labelledby="modal-label"! ! aria-describedby="modal-description">! ! <div role="document">! ! ! <h1 id="modal-label">! ! ! ! Choose account! ! ! </h1>! ! ! <p id="modal-description">! ! ! ! Description here! ! ! </p>! ! </div>!
  149. 149. Adding meaning to important actions
  150. 150. For some important actions inside the modal window, screen reader users should be given additional information to let them know what will happen.
  151. 151. Submit
  152. 152. As screen reader users are submitting form data, they should be informed that:
  153. 153. 1. they will be taken back to the parent page.
  154. 154. 2. where this data will be submitted when they return to the parent page.
  155. 155. ENTER “Submit and return to bank balance information. Your data will be added to the Balance table”
  156. 156. Close window
  157. 157. As screen reader users focus on the “Close” function, they should be informed that closing will take them back to the parent page.
  158. 158. ENTER “Leave form and return to bank balance information”
  159. 159. A question on tab order
  160. 160. Is it better to present to “Close” button before any form controls in tab order, or after any form controls.
  161. 161. A lot will depend on the complexity and amount of content inside the modal window.
  162. 162. Simple modal windows
  163. 163. For simple modal windows, it may be easier to place the “Close” button last in tab order.
  164. 164. 1
  165. 165. 2
  166. 166. 3
  167. 167. Complex modal windows
  168. 168. For complex modal windows, where users may want to go back to the parent page quickly without having to TAB through the whole window, it may be better to place the “Close” button first in tab order.
  169. 169. 1
  170. 170. 2
  171. 171. 3
  172. 172. 4
  173. 173. 5
  174. 174. 6
  175. 175. On sites where there are numerous different modal dialogs, the most important thing is consistency. Decided on a method and use it for all modal windows so that it becomes predictable.
  176. 176. After modal dialog closes
  177. 177. When the modal window is closed, if users are being taken back to the parent page:
  178. 178. 1. Focus should be placed on the relevant component of the parent page. The most common practice is to move focus back to the element that invoked the dialog.
  179. 179. The user should not be thrown back to the top of the parent page unless there is a good reason!
  180. 180. 2. The user should be informed where they are and what change has occurred.
  181. 181. ENTER
  182. 182. Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonummy nibh euismod tinunt ut laoreet dolore magna aliquam erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip vel eum iriure dolor in hendrerit in vulputate. Accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat. Heading here Another thing here Add your bank balance Another heading $1,200.34 Focus “Bank balance $1200.34 added to bank information table”
  183. 183. Thanks to…
  184. 184. A huge thanks to Roger Hudson, Steve Faulkner and James Edwards for their advice and feedback on these slides.
  185. 185. Russ Weakley Max Design ! Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley

×