UAAG LCWD feedback

Good job!

HTH

Josh

Some comments (mostly) editorial below:

# 1: In the Overview:

Some commas needed:

"Thus, many UAAG 2.0 requirements use configuration to ensure that a 
functionality designed to improve accessibility, for one user, does not 
interfere with accessibility for another."

#2: Some sentences are rather long:

Consider breaking them up, for improved readability:

eg "UAAG 2.0 encourages configuration requirements rather than 
requirements for default settings. This is because a default user agent 
setting may be useful for one user but interfere with the needs of 
another. "

#3: The phrase "interfere with accessibility" sounds odd. As an 
abstraction, it may not even be possible ;-) - see above for suggested 
change.

#3: This sentence isn't idea, and a little difficult to parse:

Firstly the line:

""For example, a feature required by UAAG 2.0 may be ineffective or 
cause content to be less accessible, [...]" may not give the best 'first 
impression' of UAAG!

To maintain the gist of the sentence and (shine a favourable light on 
UAAG, as well as it's supporting documentation etc) how about:

"For example, if some feature required by UAAG 2.0 inadvertently caused 
some content to be less accessible, it would be imperative that the user 
be able to turn off that feature. Therefore, to avoid overwhelming users 
with an abundance of configuration options, UAAG 2.0 includes 
requirements that promote clear documentation and ease of configuration."

#4: This is an important clause IMO, and isn't clear - and may also be a 
red flag for some readers. Remove - 'although author preferences are 
important' - it's much clearer as:

"In some cases, UAAG 2.0 includes requirements to override author 
preferences when the user would not otherwise be able to access 
content." A link to an example may help:

Or even better - remove the section "the user would not otherwise be 
able to access content." This may seem a little extreme but as there 
just isn't clarification, or a URI nearby this sentence may just cause 
confusion.

A way to deal with that would be to just state early on, that "In some 
cases, UAAG 2.0 includes requirements to override author preferences." - 
as this is clear statement of fact. That text could be a link to a 
section with more info on the subject, and/or later on, further down in 
the document it's expanded on to give the reader a better sense of 
context. As the wording currently is, it's sounds a little apologetic to 
me. "Oh, we know that author preferences are important but we are going 
to overide them anyway!".

My preference would be to state first that this is possible, and then in 
a relevant section - clarify and qualify the statement.

#5: Under "UAAG 2.0 Layers of Guidenace" when listing the principle, put 
a line break before the list starts, and then when it ends. It looks 
bunched up. Also line breaks after the Princliples section, Guidelines 
sections etc.

#6: Add the word 'both':

Under "Components of Web Accessibility"

"Web accessibility depends on both accessible user agents and accessible 
content. "

#7: Could you say "The level of accessibility for web content is largely 
influenced by the authoring tool used to create it."?

#7 Under "Levels of Conformance"

Remove - "Having too many options may be overwhelming for some users." 
and rearrange the sentence order as follows:

"The levels can help user agent developers decide which options to 
provide in a basic user interface, and which to provide through 
progressive disclosure to advanced users. UAAG 2.0 has many options that 
can be managed through preference settings."

#8: UAAG 2.0 Conformance Applicability Notes:

Commas needed:

" UAAG 2.0 success criteria only apply to web content, and its 
behaviors, that can be recognized by user agents."

#8: Under "UAAG 2.0 Conformance Applicability Notes:"

Could the Optional Setting text be changed to say that there is a 
preference (if this is the case, but I can't see why wouldn't be) for 
having a required behavior as a default option (where possible. For example:

"Optional Settings: Throughout UAAG 2.0, all required behaviors may be 
provided as optional preference settings unless a success criterion 
explicitly says otherwise. [...] While it is preferred to have a 
required behavior as a default option, it does not need to be, unless 
the success criteria explicitly says otherwise."

#9:

This is a little confusing:

"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language 
(must, may, should) because these are guidelines and not interoperable 
specifications. These words in UAAG 2.0 don't have the same sense as 
they do in RFC 2119."

While UAAG says it doesn't use RFC 2119 language, it obviously these 
words but with non normative implication. To say they don't have the 
same 'sense', could be improved.

How about?

"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language 
(must, may, should) as it is not an interoperable specification. Note, 
even if these terms appear from time to time they do not have any RFC 
2119 implication. " or similar.

#10: Under Guideline 1.1, Summary. Move (1.1.1) so it is before the period.

"Summary: The user can choose to render any type of alternative content 
available (1.1.1). "

The summary is a little hard to parse. I'm suggesting some 
punctuation/edits as follows:

"Summary: The user can choose to render any type of alternative content 
available (1.1.1). The user can also choose, at least one alternative 
such as alt text, to be always displayed (1.1.3). It's recommended that 
users also specify alternative content as a cascade (1.1.5). For 
example, firstly alt text, otherwise longdesc, otherwise a descriptive 
filename etc. It's recommended that the user can configure caption text 
and that a text, or sign language alternative cannot obscure the video 
or the controls (1.1.4). The user can configure the size and position of 
media alternatives (1.1.6)."

#11 Guideline 1.2 - Repair missing content [Implementing 1.2]

Would 'suitable' be better than 'useful?

Summary: The user can request suitable alternative content when the 
author fails to provide it. For example, showing metadata in place of 
missing or empty (1.2.1) alt text. The user can ask the browser to 
predict missing structural information, such as field labels, table 
headings or section headings (1.2.2).

#12: Guideline 1.3 - Provide highlighting for selection, keyboard focus, 
enabled elements, visited links [Implementing 1.3]

'And' should only be used at the end of a list of items in a clause:

Summary: The user can visually distinguish selected, focused, enabled 
items, and recently visited links (1.3.1) with a choice of highlighting 
options, that at least, include foreground and background colors, border 
color and thickness (1.3.2).

#13: Guideline 1.4 - Provide text configuration [Implementing 1.4]

Summary: The user can set text scale, color, and font family globally 
(1.4.1, Level A); set text size, color, and font family for element 
types (1.4.2, Level AA); set line spacing, character spacing, word 
spacing, text style, and justification globally (1.4.3, Level AA); set 
text style, margins, and borders for elements (1.4.5, Level AAA); set 
line spacing, capitalization, hyphenation, margins, and borders globally 
(1.4.6, Level AAA); print configured and reflowed text (1.4.4 Level AA).

#14: Guideline 1.8 - Help users to orient within, and control, windows 
and viewports [Implementing 1.8]

I'm wondering out loud if these summaries may be better as a list of 
items? This one is large and easy to get lost in IMO.

#15: PRINCIPLE 2. Ensure that the user interface is operable

Need a little rewrite/punctuation - see below:

Note: Users interacting with a web browser may do so using one or more 
input methods including keyboard, mouse, speech, touch, and gesture. 
It's critical that each user be free to use whatever input method, or 
combination of methods, that works best for a given situation.

Note: This sentence is confusing:

If every potential user task is made accessible via modality independent 
controls that any input technology can access, a user can use what works 
best.

How about?

"If every potential user task is made accessible, so multiple modalities 
are supported, that a user can choose what works best."

NOTE: I think I have a larger issue around the term "modality 
independent controls"! I know what it is saying, but I'm not sure I like it.

#16 Guideline 2.2 - Provide sequential navigation [Implementing 2.2]

Small edit:

Summary: Users can use the keyboard to navigate sequentially to all the 
operable elements in the viewport (2.2.1, Level A) as well as between 
viewports (2.2.2, Level A), and the default navigation order is [the] 
document order (2.2.3, Level A). Users can optionally disable wrapping 
or request a signal when wrapping occurs (2.2.4, Level AA).

#17: Guideline 2.3 - Provide direct navigation and activation 
[Implementing 2.3]

Small edit:

Summary: Users can navigate directly (e.g. using keyboard shortcuts) to 
important elements (2.3.1, Level AA) with the option [to immediately 
activate] operable elements (2.3.3, Level A). Display commands with the 
elements to make it easier for users to discover the commands (2.3.2 & 
2.3.4, Level AA). The user can remap and save direct commands (2.3.5, 
Level AA).

#18: Guideline 2.4 - Provide text search [Implementing 2.4]

Small edit/punctuation

Summary: Users can search rendered content (2.4.1, Level A) forward or 
backward (2.4.2, Level A) and can have the matched content highlighted 
in the viewport (2.4.3, Level A). The user is notified [in an accessible 
way] if there is no match (2.4.4, Level A). Users can also search, by 
case and for text, within alternative content (2.4.5, Level AA).

#19 Guideline 2.7 - Configure and store preference settings 
[Implementing 2.7]

Summary: Users can restore preference settings to default (2.7.2, Level 
A), and accessibility settings persist between sessions (2.7.1, Level 
A). Users can manage multiple sets of preference settings (2.7.3, Level 
AA), and adjust preference setting[s] outside the user interface, so the 
current user interface does not prevent access (2.7.4, Level AA), and 
transport settings to compatible systems (2.7.5, Level AA).

#20 Guideline 2.11 - Provide control of time-based media [Implementing 2.11]

Rework of 'and' in a single clause:

Summary: The user can present placeholders for time-based media (2.11.1, 
Level A) and executable regions (2.11.2, Level A), or block all 
executable content (2.11.3, Level A), adjust playback (2.11.4, Level A), 
stop/pause/resume (2.11.5, Level A), navigate by time (2.11.6, Level A) 
or semantic structures such as chapter (2.1.7, Level AA), enable or 
disable tracks (2.11.8, Level AA), adjust contrast and brightness of 
visual time-based media (2.11.9, Level AAA).

#21 Guideline 2.12 - Support other input devices [Implementing 2.12]

Is platform plural needed? The possessive clause is implied already.

Summary: User agents support all of the platform text input devices 
(2.12.1, Level A), and for all input devices the user can input text 
(2.12.3, Level AAA) and perform all other functions (2.12.2, Level AA).

#22 Guideline 5.1 - Comply with applicable specifications and 
conventions [Implementing 5.1]

Remove "including by":

Summary: When the browser's controls are authored in HTML or similar 
standards, they need to meet W3C's Web Content Accessibility Guidelines 
(5.1.1, Levels A, AA, AAA). The user agent supports the accessibility 
features of content formats (5.1.2, Level A) and of the platform (5.1.3, 
Level A), allows handling of unrendered technologies (5.1.4, Level A) 
alternative viewers (5.1.5, Level AA), and allows users to report 
accessibility issues (5.1.6, Level AAA).

Received on Friday, 24 January 2014 11:10:18 UTC