Thread Subject: Re: Text and the importance of programmatically determinable

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Peter Korn
Date: Tue, Mar 18 2008 5:05 PM

Hi Gregg,

Now you sound a bit like me and me like you. You argued that words mean
what we define them to mean, so if we defined "accessible text" as PD
(and expressly not addressing colorblind), then we'd be OK.

For myself, I'm not tied to the term "accessible text". "e-text" or
something else would likely be fine (pending the word/phrase suggested).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Interesting thought. I worry about the word "accessible" though.
>
>
>
> People who are colorblind would not consider "programmatically
> determinable text" accessible nor would people with cognitive,
> language or learning.
>
>
>
> It would also add length to a lot of provisions.
>
>
>
> BUT on the positive side it lets 'text' have its broader common
> meaning.
>
>
>
> I thought of using e-text years ago (in WCAG) to do this but people
> thought this was too 'tech-y' or hard to read.
>
>
>
>
>
>
>
> Can anyone think of something that would allow us to have two types of
> Text generic text which we wouild call text and programmatically
> determinable text that we would call...... what? e-text is
> awkward. 'accessible-text' isn't accurate (or is one-disability
> accessible) pd-text?
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
> If Attachment is a mail.dat try http://www.kopf.com.br/winmail/
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Peter Korn
> *Sent:* Tuesday, March 18, 2008 11:48 AM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Text and the importance of
> programmatically determinable
>
> Hi all,
>
> I think what makes the most sense is to define "text" as a variant
> of what Andi put forth, and to define "accessible text" using PD
> language (that we when call out to the Access Board on the topic
> of whether or not PD is defined in terms of what existing &
> commercially available AT are already using). We can do this in
> the same definition block of text, with a second paragraph
> detailing "accessible text". Then it is a simple editorial change
> to make "text" be "accessible text" in most places in the document.
>
> This preserves the meaning of "text" that most engineers will
> understand, and makes clear everywhere in the document where we
> mean it to be so that we are talking about a particular variant of
> "text" that has the additional property of being accessible.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
> Hi
>
> I also had run a complete analysis -- but was hesitant to post it.
>
> But since it came up with a different conclusion here it is.
>
> I agree that clearing up text would cause us to need to change
> some provisions or definitions (just 3)
>
> But if we do not make it clear in the definition that text must be
> PD it would cause us to have to change 25.
>
> Several that Sean posted are already fixed in today's drafts -- or
> are not a problem (see below). They don't require text to be
> programmatically determined, but the wording of the provisions
> accounts for that definition. For example they already say
> "text or images of text"
>
>
> * For all 25 of these provisions it is essential that text
> be electronically accessible by AT or the provisions do not
> work. *
>
> 1. Note: Simple text editors that can only create or modify
> content in conforming formats by directly editing the code
> are not considered authoring tools under this definition.
> 2. Note 1: CAPTCHA tests often involve asking the user to type
> in text that is presented in an obscured image or audio file.
> 3. *Content *(Consensed) Information and sensory experience to
> be communicated to the user by means of software, including
> but not limited to: text, images, sounds, videos, controls
> and animations, as well as the encoding that defines the
> structure, presentation, and interactions associated with
> those elements. For example: word processing files,
> presentation files, spreadsheet files, text files, portable
> document files, web based content, etc.
> 4. *Label* (Consensed) Text or other component with a text
> alternative that is presented to a user to identify a
> component within content.
> 5. *Non-text Object *(Consensed) Any object that is not a
> sequence of characters that is programmatically determinable
> or where the sequence is not expressing something in human
> language. *Note*: This includes, but is not limited to,
> ASCII Art (which is a pattern of characters), emoticons,
> leetspeak (which is character substitution), and images
> representing text.
> 6. *Real-time Text: *Communications that employ the
> transmission of text wherein the characters are transmitted
> by a terminal within a maximum of 1 second of character
> input. This would typically be for conversational purposes
> but also may be used in voicemail, IVR and other similar
> applications. {TTYs are AT and need to access this -- and
> IP real-time text AT needs to be able to receive the IPtext
> (and translate into different forms -- for example braille
> for those who are deafblind.}
> 7. *Text:* Sequence of characters that is programmatically
> determinable, where the sequence is expressing something in
> human language.
> 8. *TTY *(Consensed) An abbreviation for teletypewriter.
> Machinery or equipment that enables interactive text based
> communications through the transmission of
> frequency-shift-keying audio tones across the PSTN according
> to TIA-825-A (A Frequency Shift Keyed Modem For Use On The
> Public Switched Telephone Network). As used in this part,
> the term TTY includes devices for text-to-text
> communications along with voice and text intermixed
> communications such as voice carry over and hearing carry
> over. TTYs may include computers with special modems. TTYs
> are a subset of devices called text telephones.
> 9. *1-C - Pass Through* (Consensed): Products that transmit
> or conduct information or communication must preserve
> accessibility information that is transmitted in
> non-proprietary, industry-standard codes, translation
> protocols, or formats. Technologies which use encoding,
> signal compression, format transformation, or similar
> techniques must not remove information needed for access, or
> must restore it upon delivery. Firewalls, routers,gateways
> and other products that pass real-time voice communication
> must also pass real-time text communication signals
> (including mixed voice and real-time text) that are standard
> in the United States for that technology platform without
> distortion or error beyond 1%. {See real-time-text
> definition above. Must be accessible by AT}
> 10. *1-E - Visual Information* (Partial recommendation, No
> quorum) Version 2 All information that is needed for
> operation and use that is provided in visual form must also
> be available in at least one mode in audio form or in simple
> tactile form, either directly or {ending to be determined in
> AT discussion}. Visual content that includes text and that
> is closed due to Digital Rights Management (DRM) such that
> it cannot be rendered in audio form by AT and other players
> must include an audio form that can be. *Note* 1: Section
> 255 and Section 508 treat AT solutions differently, so
> review section XX of this document before implementing a
> solution. *Note* 2: Braille is not a simple tactile form.
> It is encouraged but cannot be used to satisfy this
> provision. {This clearly says that the text -- which would
> otherwise be accessible to AT is rendered in such a way that
> it is not}.
> 11. *3-A - Color *(Consensed): Color must not be used as the
> only visual means of conveying information, indicating an
> action, prompting a response, or distinguishing a visual
> element. Example: A conforming example is mandatory form
> fields are identified with colored text and labeled as
> "Required". { This is an example and if field is
> identified by text -- then the text needs to be accessible
> by AT (by non-text provision) in order to be the means for
> identifying. Otherwise this example would be written
> "visually identified" Also, if identification was not
> accessible to AT then the example would show that the person
> could tell it was required but provide no means for
> identifying what to put into the field.}.
> 12. *3-F - Non-text Objects* (Consensed)All non-text objects
> that are presented to the user must have a text alternative
> that presents equivalent information, except for the
> situations listed below.
>
> 1. Controls-Input: If a non-text object is a control or accepts
> user input, then it must have a name that describes its purpose.
> (See also User Interface Components provisions)
>
> 2. Media: If a non-text object is synchronized media, live
> audio-only or live video-only content, then text alternatives must
> at least provide a descriptive label that identifies the non-text
> object. (For synchronized media, see also Audio and/or Video
> provisions)
>
> 3. Test: If a non-text object is a test or exercise that must be
> presented in non-text format, then text alternatives must identify
> at least the non-text object with a descriptive text label. (For
> synchronized media, see also Audio and/or Video provisions)
>
> 4. Sensory: If a non-text object is primarily intended to create a
> specific sensory experience, then text alternatives must identify
> at least the non-text object with a descriptive text label. (For
> synchronized media, see also Audio and/or Video provisions)
>
> 5. CAPTCHA: If the purpose of a non-text object is to confirm that
> content is being accessed by a person rather than a computer then
> text alternatives that identify and describe the purpose of the
> non-text object must be provided and alternative forms in
> different modalities must be provided to accommodate different
> disabilities.
>
> 6. Decoration, Formatting, Invisible Objects: If a non-text object
> is pure decoration, or used only for visual formatting, or if it
> is not presented to users, then it must be implemented such that
> it can be ignored by assistive technology.
>
> Note: In order to satisfy this provision, non text objects in data
> operated on by the software would need to be associated with
> textual equivalents that the software can obtain as readily as it
> can obtain the non-text object itself. Where a non-text object is
> a scanned image of text, textual equivalents would need to allow
> for the inclusion of the text of the scanned image of text. Where
> a non-text object is a dynamic presentation, graphs, or other
> derived information from a data source, textual equivalents would
> need to allow for the inclusion of the data used
>
> <!--[if !supportLists]-->13. <!--[endif]-->*3-G - Human Language
> *(Consensed): When supported in the technologies of electronic
> documents, the default human language of electronic document must
> be programmatically determinable. *Note*: In order to achieve
> this provision, text encoded in data operated on by the software
> would need to be associated with sufficient information to
> identify both the primary language of the text, and the language
> of any sections or the text that are in another language from the
> primary language, that the software can obtain as readily as it
> can obtain the text itself.
>
> <!--[if !supportLists]-->14. <!--[endif]-->*3-N - Link Purpose
> *(Consensed): On Web pages, it must be possible to determine the
> purpose of each link from the link text or the link text together
> with its programmatically determinable link context. *Note:* In
> order to achieve this provision, links encoded in data operated on
> by the software would need to be associated with link text that
> the software can obtain as readily as it can obtain the link itself.
>
> <!--[if !supportLists]-->15. <!--[endif]-->*3-O - Information
> and Relationships* (Consensed): Information and relationships
> conveyed through presentation of electronic documents must be
> either programmatically determinable or available in text, and
> notification of changes to these is available to user agents,
> including assistive technologies.
>
> <!--[if !supportLists]-->16. <!--[endif]-->*3-P - User Interface
> Components: * ..... Example: Frames must be titled with
> text that facilitates frame identification and navigation.
>
> <!--[if !supportLists]-->17. <!--[endif]-->*3-S - Keyboard
> Operation: *(Consensed): ...... Note 2: The exception
> relates to the underlying function, not the input technique. For
> example, if using handwriting to enter text, the input technique
> (handwriting) requires path dependent input but the underlying
> function (text input) does not.
>
> <!--[if !supportLists]-->18. <!--[endif]-->*3-NEW - Visual
> Indication of Keyboard Shortcuts *: All keyboard commands
> associated directly with user interface controls must be visible
> within the visual user interface in at least one mode, and
> available programmatically to AT on products that support AT
> interoperability. Note 1: This includes commands such as those
> used to active a menu item or button (e.g. the "S" of a "Save
> File" menu item), but does not include commands that are
> system-wide or common conventions for using an item (e.g. a
> command to switch windows such as ALT-TAB, or a command to advance
> the caret in text such as Ctrl-Arrow). Note 2: User-configurable
> keyboard commands may be considered not directly tied to interface
> elements. However, when possible such user-configurable keyboard
> bindings should be visually presented as configured.
>
> <!--[if !supportLists]-->19. <!--[endif]-->*3-U - AT
> Interoperability* (Discussed March 4, partial consensus): On
> platforms that support AT-E&IT interoperability, software that
> provides user interface components must either use the
> accessibility services provided by platform software or other
> services to cooperate with assistive technologies when such
> services allow the software to meet the accessibility provisions
> of this standard.
>
> Using such services, software must:
>
> 1. expose object information including but not limited to:
>
> a. role, state(s), boundary, name, and description
>
> b. the row and column a component is in, and the headers for the
> row and column for that component if it is in a table that has row
> or column headers,
>
> c. current value and any minimum or maximum values, if the
> component represents one of a range of values
>
> d. relationship this component has as a label for another
> component, or being labeled by another component
>
> e. name of parent or containing element, and any children components
>
> f. text contents, text attributes, and the boundary of text
> rendered to the screen
>
> g. keyboard shortcuts and implicit designators.
>
> In order to meet this provision, interactive elements encoded in
> data operated on by the software must be associated with
> sufficient information to programmatically determine a role,
> state(s), name, and description for the interactive element, that
> the software can obtain as readily as it can obtain the
> interactive element itself.
>
> 2. expose a list of actions that can be executed on an object and
> allow assistive technology to programmatically execute any of
> those actions;
>
> Proposed revision to #2 from Sean, March 5: Note 2: expose a list
> of actions that can be executed on an object and allow
> programmatic execution of any of those actions;
>
> 3. expose information necessary to track and modify: focus, text
> insertion point, and selection attributes of user interface
> components;
>
> 4. expose notification of events relevant to user interactions,
> including but not limited to changes in the component's state(s),
> value, name, description, or boundary
>
> Note 1: This provision also applies to forms in the software.
>
> Note 2: Software that provides remote access to graphical user
> interfaces (GUIs) would need to ensure that AT has access to the
> information required by this provision. There are two known ways
> to accomplish this: run the AT remotely as well or run the AT
> locally and provide a mechanism for it to communicate
> accessibility information with the remote GUI.
>
> Note 3: The term 'assistive technology' in this provision and
> provision 3-V-Accessibility Services refers to assistive
> technology that exists and that is available to government
> employees (or members of the public for public facing E&IT). If no
> AT exists for a given platform or application at the time of
> procurement then the technical provisions should still be met in
> absence of AT and the FPC should, as in all cases, be used as a
> guide toward measurement of overall accessibility.
>
> <!--[if !supportLists]-->20. <!--[endif]-->*3-AA - Error
> Identification* (Consensed): If an input error is automatically
> detected in content or electronic documents, the item that is in
> error must be identified and described to the user in text.
>
> <!--[if !supportLists]-->21. <!--[endif]-->*5-B - Video
> Description* (Consensed): Materials containing video and/or
> audio, regardless of format, that contain visual information
> necessary for the comprehension of the content, must comply with
> the following:
>
> 1. Materials containing prerecorded video and no original audio or
> other additional time-based content must provide either a separate
> text description of the video or provide an additional audio track
> to convey the informational content of the video.
>
> 2. When the visual informational content is not conveyed through
> other means, materials containing prerecorded video with
> concurrent audio must provide synchronized video descriptions, or
> when space is not available in the main program audio for
> synchronized video descriptions, a separate text description of
> the video content must be provided.
>
> 3. Materials containing live video must provide synchronized video
> descriptions in real time to convey any informational content of
> the video that is not conveyed through other means.
>
> <!--[if !supportLists]-->22. <!--[endif]-->*6-A - Real-Time Text
> Reliability and Interoperability *(Consensed): If hardware or
> software provides real-time voice conversation functionality it
> must provide at least one means of real-time text communication
> where the following reliability requirements are met:
>
> 1. Products must use a real-time text (RTT) system that meets the
> following requirements:
>
> * a. RTT format must be a standard real-time text format for
> the voice platform that is supported by all terminal, router,
> gateway and other products on that platform;
>
> * b. RTT format must transmit characters with less than 1
> second delay from entry;
>
> * c. RTT system must transmit text with less than 1% Total
> Character Error Rate at the peak network traffic specified for
> intelligible speech transmission (text must work on the network as
> long as speech does);
>
> * d. The RTT system, together with the audio system, must
> support speech and text in both directions in the same call
> session (and support speech and text simultaneously in both
> directions in the same call session if IP based)
>
> * e. RTT system must not utilize audio tones for transmission
> of real-time text over IP. Note: this is subject to a waiver of
> the TTY support requirement from the FCC for systems that
> implement IP based RTT. Also subject to consumer acceptance of
> prefixes or phone numbers to direct TTY traffic to gateways
> capable of handling TTY translation.
>
> 2. Where products or systems interoperate outside of their closed
> systems, they must:
>
> * a. If product interfaces with PSTN, it must use TIA 825A
> Baudot where it interfaces to the PSTN.
>
> * b. If product interfaces with other VoIP products or systems
> (outside of a self-contained product-system) using SIP it must
> support transmission of text as per XXX where it interfaces with
> other VoIP products or systems. Note: this is subject to a waiver
> of the TTY support requirement from the FCC for systems that
> implement IP based RTT. Also subject to consumer acceptance of
> prefixes or phone numbers to direct TTY traffic to gateways
> capable of handling TTY translation.
>
> * c. If product connects to other products or systems using a
> protocol other than SIP it must use the standard real-time text
> protocol that meets provision 1 above that has been established
> for that protocol.
>
> Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored
> to fill the role of XXX. The intention is that XXX will be
> replaced by one interconnection format in all places it was used.
>
> Note 2: All products may support and use other protocols in
> addition to these as long as they meet the 5 requirements of
> 5-B(1) above.
>
> Note 3: A self-contained SIP system that uses the same real-time
> text protocol can be treated as a single product and can use any
> protocol internally as long as it supports XXX where the
> system-product connects to other systems or products.
>
> <!--[if !supportLists]-->23. <!--[endif]-->*6-B - Voice Terminal
> Hardware and Software* (Consensed, still have items to resolve)
> Terminal hardware or software that is capable of providing voice
> communications in real-time must comply with the following:
>
> 1. Receive only: If hardware or software terminal provides voice
> conversation over IP in any form, and has a user interface with a
> multi-line display or a user interface that runs on devices that
> have a multi-line display, then that terminal must display any
> real-time text that is received if it is received in the format
> for the voice and real-time text system being used on the network
> on which it is installed.
>
> 2. Send and Receive: If terminal hardware or software provides
> voice conversation over IP in any form, and has text generation
> capability, then the terminal must allow users to send real-time
> text in the format for the voice and real-time text system being
> used on the network on which it is installed.
>
> 3. If IP terminal hardware or software does not provide real-time
> text send and receive capability then the terminal must support
> the addition of terminals and terminal peripheral equipment that
> do support real-time text functionality in conjunction with the
> voice call functionality, in the same location and with the same
> permissions for use as their voice terminal. If the terminal is in
> a public or shared area and not in an individual's private work
> area then the connection must be possible [without requiring
> system-administrator intervention]. Note: the "without
> system-administrator intervention" is a serious concern due to
> security issues, but removal would prevent people from connecting
> devices outside of their home system. Additional work is needed to
> address this issue.]
>
> 4. If terminal is analog or TDM-digital wired terminal then it
> must support the connection of a TTY via an RJ-11 jack in the same
> location and with the same permissions for use as the telephone
> and it must be capable of allowing simultaneous speech and text
> conversation without interference or its microphone must be
> capable of being turned on and off to allow the user to intermix
> speech with text use.
>
> Note 1: Provision of the RJ-11 jack may be accomplished through
> one of the following techniques:
>
> a. provision of the RJ-11 jack on the telephone,
>
> b. the use of a Y-adapter that allows both the analog telephone
> and the TTY to be plugged into the same line outlet,
>
> c. having built in capability to support an RJ11 module that can
> provide a connection point for TTYs.
>
> Note 2: The standard format for PSTN is TIA-825A. For SIP is it
> XXX. For other voice transport protocols the format is to be
> determined by the entity responsible for the voice transport protocol.
>
> <!--[if !supportLists]-->24. <!--[endif]-->*6-C - IVR,
> Auto-Attendant and Messaging *(Consensed): Voice mail, messaging,
> auto-attendant, and interactive voice response telecommunications
> systems must provide access in the following manner: 1) All
> functions that are accessible to voice users must also be directly
> accessible to users of real-time text. <SNIP>
>
> <!--[if !supportLists]-->25. <!--[endif]-->* 2. Text
> descriptions: *Documentation and training materials should
> include text descriptions of the interface. These descriptions
> should stand on their own and be understandable without relying on
> graphic images in the materials.
>
>
> */4 Places where PD is not required but current language
> accounts for PD definition of text. (in fact- assumes it) /*
>
> 1. ** Large Scale Text *(Consensed) At least 18 point or 14
> point bold {In provision we actually say large scale
> text or images of large scale text}
>
> <!--[if !supportLists]-->2. <!--[endif]-->** 3-T - Focus
> Indicator* (Consensed): Any keyboard operable user interface must
> support a mode of operation where the indication of keyboard focus
> has a high degree of visibility. Note 1: The presence of a highly
> visible text insertion point is sufficient for a text area. Note
> 2: A focus cursor that is visually locatable at 3.5 times the
> typical viewing distance without moving the cursor by people who
> have unimpaired vision and are familiar with what the focus cursor
> looks like is sufficient. For example, when software is displayed
> on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels
> resolution, a focus cursor that is visually locatable at 2.5
> meters without moving the cursor by people who are familiar with
> what the cursor looks like and have unimpaired vision is sufficient.
>
> 3. ** 3-B - Contrast *(Consensed) Presentation of text, and
> images of text, in electronic documents must have a contrast
> ratio of at least 5:1, except for the following: * Large
> Print: Large-scale text and images of large-scale text must
> have a contrast ratio of at least 3:1; * Incidental:
> Text or images of text that are part of an inactive user
> interface component, that are pure decoration, that are
> incidental text in an image, or that are not visible to
> anyone, have no minimum contrast requirement.
>
> <!--[if !supportLists]-->4. <!--[endif]-->** 3-D - User
> Preferences *(Consensed) Applications must provide a mode that
> utilizes platform settings for color, contrast, font type, font
> size, and focus cursor. In the absence of platform settings for
> color and contrast, all text (and images of text) must have a
> contrast ratio of at least 5:1 except for the following: *
> Large Print: Large-scale text and images of large-scale text must
> have a contrast ratio of at least 3:1; * Incidental: Text or
> images of text that are part of an inactive user interface
> component, that are pure decoration, that are incidental text in
> an image, or that are not visible to anyone, have no minimum
> contrast requirement.
>
> <!--[if !supportLists]-->5. <!--[endif]-->*Captions (new
> wording )*
>
> <!--[if !supportLists]-->6. <!--[endif]-->
>
>
> */Places where text being PD would require a change /*
>
> The following items would need small changes like adding "and
> images of text". This would be needed in order to make their
> wording consistent with other provisions anyway.
>
>
> *Contrast Ratio (Consensed) (just changing some
> informative notes)*
>
> *Note 3:* Text *AND IMAGES OF TEXT* can be evaluated with
> anti-aliasing turned off.
>
> *Note 4:* Background color is the specified color of content over
> which the text* OR IMAGE OF TEXT* is to be rendered in normal
> usage. If no background color is specified, then white is assumed.
>
> *Note 5:* For* *text *OR IMAGES OF TEXT *displayed over gradients
> and background images, authors should ensure that sufficient
> contrast exists for each part of each character in the content.
>
>
> *Video Description *
>
> The insertion of verbal or auditory description(s) of on-screen
> visuals intended to describe important visual details that are not
> contained in, or that cannot be understood from, the main audio
> output alone. Video descriptions supplement the regular audio
> track of the program and are usually inserted between dialogue
> narration to provide information about actions, characters, and
> on-screen text* OR IMAGES OF TEXT* that appear without
> verbalization. Video descriptions are a way to let people who are
> blind or have low vision know what is happening on screen.
>
>
> *1-G - Text size (Discussed Feb 7, 12, 19)*
>
> There must be at least one mode where all information that is
> required for product use and is provided in text *OR IMAGES OF
> TEXT* is readable by people with 20/20 vision at 3.5 times their
> typical viewing distance. This mode must be the default mode
> unless the activation method for that mode can be done at 3.5
> times the typical viewing distance or the product automatically
> sets itself to that mode for users who require it. This provision
> does not apply to safety labels, regulatory labels, and marks that
> are not required for product use. /This requirement does not apply
> to the caption decoding functions of products that are governed by
> U.S. Federal Communications Commission (FCC) regulations 47 CFR
> 15.119 or to devices which provide equivalent functionality as
> stipulated by 4-A - Caption Processing/
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<_http://trace.wisc.edu/_>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University