[Bug 21102] proofreading / typos

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21102

dmacdona <david100@sympatico.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david100@sympatico.ca

--- Comment #1 from dmacdona <david100@sympatico.ca> ---
The following are just proofreading recommendations for enhanced readability.
They are by no means bugs and should not be treated as such.

Recommendation 1:
The second paragraph of section '1.Introduction' reads:
"This document suggests which ARIA attributes it is appropriate to use..."

For grammatical coherence it should read:
"This document suggests which ARIA attributes *are* appropriate to use..."
DONE
=======
Recommendation 2:
The third paragraph of section '1.Introduction' reads:
"For general best-practice information for using ARIA, see the..."

It would be more appropriate if it read:
"For general best-practice information *about* using ARIA, see the..."
DONE
======
Recommendation 3:
The second paragraph of section '2.3 Third rule of ARIA use' reads:
"If you create a widget that a user can click or tap or drag or drop or slide
or scroll a user must also be able navigate to the widget and perform an
equivalent action using the keyboard."

My recommendation here is that it read:
"If you create a widget that a user can click or tap or drag or drop or slide
or scroll*,* a user must also be able *to* navigate to the widget and perform
an equivalent action using the keyboard.

DONE

=======
Recommendation 4:
The second <h3> of the section '2.4 What does adding a role do to the native
semantics?' reads:
"What adding a role does not do?"

Expressing this as a question obscures the simplicity of what the spec intends
to say, making it less understandable for people who's English skills are not
that great, so my recommendation is that it merely say: "What adding a role
does not do", without the question mark.
DONE
=========
Recommendation 5:
The penultimate paragraph of the above section reads:
"But it can still be pressed, it is still in the default tab order, still looks
like a button, still triggers any associated actions when pressed."

Grammatically this is not wrong, but it leaves the reader with a taste that
he/she is missing something, as if the information was not complete, and they
may want to re-read the phrase to make sure he/she hasn't missed something.
Therefore I would recommend that it read:
"But it can still be pressed, it is still in the default tab order, still looks
like a button *and* still triggers any associated actions when pressed."
DONE
========
Recommendation 6:
The second half of the first paragraph of the section '2.5 Add ARIA inline or
via script?' reads:
"If the content and interaction is only supported in a scripting enabled
browsing context, for example Google docs applications require JavaScript
enabled to work, so it is safe for them to include the ARIA markup inline."

Here there are two issues: the first one is that 'scripting enabled' should be
hyphenated as they form one compound adjective, and the second one is that the
whole phrase doesn't make a lot of sense the way it stands. My recommendation
is that it read:
"If the content and interaction is only supported in a scripting-enabled
browsing context, i.e. Google Docs (its applications require JavaScript enabled
to work), it is safe to include the ARIA markup inline."

DONE combined with prior bug filed on this paragraph by another
========
Recommendation 7:
The last phrase of the first paragraph on the '2.6 ARIA validation' section
reads:
"[...] but validation tools will produce errors when they encounter ARIA markup
as the associated DTDs have not been updated to recognise ARIA markup and it is
unlikely they ever will be."

This assumes that none of the DTDs associated to any validators are up to date,
which might be perfectly true (I don't claim to know anything about
validators), but I find it rather assuming to express it in this manner. My
recommendation for this would be: 
"[...]but validation tools will produce errors when they encounter ARIA markup
*if* the associated DTDs have not been updated to recognise *them*, which,
unfortunately, is the most likely case scenario and likely to remain so.

WONTFIX the paragraph is accurate... only html5 validators will not throw
errors.

=========
Recommendation 8:
The first paragraph on the section '2.8 aria-labelledby and aria-describedby'
reads:
"Currently aria-labelledby and aria-describedby are more robustly supported for
associating text content to a subset of interactive content elements, they do
not work correctly on links, support on embedded content is unknown, but can be
safely used on form controls including the many input types."

This paragraph also makes arguable sense from a grammatical point of view. My
recommendation is that it read:
"Currently aria-labelledby and aria-describedby are more robustly supported for
associating text content to a subset of interactive content elements*. They* do
not work correctly on links *and their* support on embedded content is unknown,
but *they* can be safely used on form controls including the many input types.

Previously FIXED
===========
Recommendation 9:
The end of the second <p> under the section '2.9 Using ARIA role=application'
reads as follows:
"Screen readers and other assistive technologies that support WAI-ARIA will
support switching between browse and focus modes for these by default, too:"

In here the comma just before too is incorrect. Therefore, it should read:
"Screen readers and other assistive technologies that support WAI-ARIA will
support switching between browse and focus modes for these by default too:"

DONE
==========
Recommendation 10:
Within the same section, the third <li> of the second <ul> should have a comma
right before 'etc', so it should read:
"table that has focusable items and is being navigated via the arrow keys, for
example a list of e-mail messages where you provide specific information. Other
examples are interactive grids, tree grids*,* etc.

DONE
===========
Recommendation 11:
In the same <ul>, the fifth <li> reads:
"[...]These cause screen readers to go into a sort of application mode
implicitly once focus moves to a control inside them."

This is a pretty weird use of the adverb implicitly, in its stead, I would
write: 
"[...]These cause screen readers to go into a sort of *implicit* application
mode once focus moves to a control inside them."

WONT FIX... a little weird yes, but it is describing a "sort of" behaviour 
...but put brackets around implicitly.

===========
Recommendation 12:
Still within the '2.9 Using ARIA role=application', its third <p> reads:
"You only want to use role=application if the content you’re providing consists
of only interactive controls, and of those, mostly advanced widgets, that
emulate a real desktop application[...]"

Here we have an extra comma, just before 'that', that should not be there:
"You only want to use role=application if the content you’re providing consists
of only interactive controls, and of those, mostly advanced widgets that
emulate a real desktop application[...]"

DONE
=======
Recommendation 13:
In that very same paragraph, the text continues:
"[...]be it FaceBook posts and comments, blogs, Twitter feeds, even accordions
that show and hide certain types of information dynamically."

There are two problems here: the first one is that 'FaceBook' should be written
'Facebook' (not that I care very much for them, but it's their branding and we
cannot mess with that); the second one is, again, punctuation. The last comma
should have been an 'or' or an 'and' to make the list grammatically correct, or
there should have been an ellipsis after the word 'feeds':

a) "[...]be it FaceBook posts and comments, blogs, Twitter feeds or even
accordions that show and hide certain types of information dynamically. "

b) "[...]be it FaceBook posts and comments, blogs, Twitter feeds..., even
accordions that show and hide certain types of information dynamically. "

DONE
======
Recommendation 14:
Still in this section, the fourth <p> reads:
"In short: The times when you actually will use role=application is probably
going to be in very rare cases!"
which is a bit of a grammatical incoherence.

Instead, it should read something along the lines of:
"In short: The times when you actually will use role=application are going to
be very rare!"

DONE
========
Recommendation 15:
The first <p> after the <h3>So where do I put role=application in the rare
cases it is useful?<h3> reads:
"[...]for example the parent div of your element that is your outer most widget
element.[...]"

The problem here is that 'outer most' is one word. Therefore:
"[...]for example the parent div of your element that is your *outermost*
widget element.[...]" should be written instead.

DONE
=======
Recommendation 16:
At the beginning of the section '2.10 Recommendations Table:', the first <li>
finishes like so:
"There are notes indicating under certain circumstances default semantics are
useful."

I'm pretty sure what the spec meant in this point is that:
"There are notes indicating under *which* circumstances default semantics are
useful."

N.B.: on the next <li>, the N/A one, the anchor leaves the 'I' of 'API' behind.

DONE
=======
Recommendation 17:
Just a little bit further, the text goes on to say:
"NONE = the element does not support ARIA roles, states and properties, this is
usually because the element is not displayed in the document."

Again, punctuation. Before 'this' there should have been a full stop:
"NONE = the element does not support ARIA roles, states and properties*. This*
is usually because the element is not displayed in the document."
DONE

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 15 January 2014 00:08:40 UTC