New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: fix typo and couple grammatical errors in Readme #544

Merged
merged 2 commits into from Feb 3, 2019

Conversation

Projects
None yet
4 participants
@hozefaj
Copy link
Contributor

hozefaj commented Feb 3, 2019

fixed typos and grammatical errors in the docs

@coveralls

This comment has been minimized.

Copy link

coveralls commented Feb 3, 2019

Coverage Status

Coverage remained the same at 99.457% when pulling d8ce7b5 on hozefaj:master into 33a7d69 on evcohen:master.

@coveralls

This comment has been minimized.

Copy link

coveralls commented Feb 3, 2019

Coverage Status

Coverage remained the same at 99.457% when pulling d93de5b on hozefaj:master into 33a7d69 on evcohen:master.

@ljharb
Copy link
Collaborator

ljharb left a comment

Are the rest of these just rebalancing the line breaks? Why?

Show resolved Hide resolved README.md
@hozefaj

This comment has been minimized.

Copy link
Contributor Author

hozefaj commented Feb 3, 2019

Yeah I guess my editor is adding them in save

@hozefaj

This comment has been minimized.

Copy link
Contributor Author

hozefaj commented Feb 3, 2019

Do you need me to remove it?

@ljharb

This comment has been minimized.

Copy link
Collaborator

ljharb commented Feb 3, 2019

Not a huge deal, but nice to avoid unnecessary diffs.

@hozefaj

This comment has been minimized.

Copy link
Contributor Author

hozefaj commented Feb 3, 2019

Will do.

@@ -291,8 +291,8 @@ You can also see a text-based version of the AX Tree in Chrome in the stable rel
### Pulling it all together
A browser constructs an AX Tree as a subset of the DOM. ARIA heavily informs the properties of this AX Tree. This AX Tree is exposed to the system level Accessibility API which mediates assistive technology agents.

We model ARIA in the [aria-query](https://github.com/a11yance/aria-query) project. We model AXObjects (that comprise the AX Tree) in the [axobject-query](https://github.com/A11yance/axobject-query) project. The goal of the WAI-ARIA specification is to be a complete declarative interface to the AXObject model. The [in-draft 1.2 version](https://github.com/w3c/aria/issues?q=is%3Aissue+is%3Aopen+label%3A%22ARIA+1.2%22) is moving towards this goal. But until then, we must consider the semantics constructs affored by ARIA as well as those afforded by the AXObject model (AXAPI) in order to determine how HTML can be used to express user interface affordances to assistive technology users.

This comment has been minimized.

@hozefaj

hozefaj Feb 3, 2019

Author Contributor

the change here is fixing the spelling error affored


### The Accessibility (AX) Tree & DOM
From the [W3 Core Accessibility API Mappings 1.1](https://www.w3.org/TR/core-aam-1.1/#intro_treetypes)

> The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.
> The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally, if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.

This comment has been minimized.

@hozefaj

hozefaj Feb 3, 2019

Author Contributor

here the difference is grammer.....from should be exposed to an assistive technology to should be exposed to assistive technology don't need the an here

This comment has been minimized.

@ljharb

ljharb Feb 3, 2019

Collaborator

Both are correct; the change seems slightly better tho.

This comment has been minimized.

@hozefaj

hozefaj Feb 3, 2019

Author Contributor

All changes are done. Ready to be merged.

@hozefaj hozefaj force-pushed the hozefaj:master branch from d8ce7b5 to d93de5b Feb 3, 2019

@ljharb

ljharb approved these changes Feb 3, 2019

@evcohen evcohen merged commit 689d0d7 into evcohen:master Feb 3, 2019

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment