10000 Aria attributes, roles, etc · Issue #48 · anvk/a11yAccordion · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Aria attributes, roles, etc #48

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.

Sign up for GitHub

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

Jump to bottom
Open
rootical opened this issue Apr 25, 2019 · 1 comment
Open

Aria attributes, roles, etc #48

rootical opened this issue Apr 25, 2019 · 1 comment

Comments

@rootical
Copy link

Hello. I wonder why there're no aria-labels, aria-expanded, hidden, roles and other things necessary according to WAG and other a11y standards.
So how comes it's accessible?
@anvk
Copy link
Owner
anvk commented Apr 25, 2019

Hi @rootical

To answer this question you should ask what "accessible" means? You can find and read about this topic everywhere online. This is just one of the online examples:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the Web, contribute to the Web.

Taken from www.w3.org

The attributes you specified above could help you to make of your code accessible out of the box (thanks to the modern browser support) but they do not necessarily guarantee that. Adding them to your code would not make magically things accessible, you still have to do extra work to ensure this.
If you ask a person (let's say with visual visual impairment) and tell them that your code has those attributes and hence it is accessible - it would not make much sense for them. Your "work" is accessible when it works well with assistive technology OR even better let people with different range of abilities to test it (color blindness, visual impairment, etc).

Now going back to the a11yAccordion. Yes you are right there. This code does not have those attributes you have specified. But at the same time were just in their experimental stage 3 years ago.
What is important is that a11yAccordion was tested using different assistive technologies (JAWS, Mac built-in text-to-speech) as well as it was tested by various users with a range of abilities. Furthermore, this component was also used in ATutor which is LMS for students with various needs. ATutor in fact was written by the same developer who created AChecker mentioned as the tool to test your websites for accessibility on https://www.ontario.ca/page/how-make-websites-accessible

The only concern is that a11yAccordion was written and tested a while ago. I'm not sure how much browsers and assistive technology has changed since then. But then this code uses pretty standard DOM properties so I doubt that it would be much different.

@rootical I hope it answers your question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@anvk @rootical
0