New answers tagged

2

role="alert" should be all you need (it has an inherent live region behaviour) although I suspect best practice is to also include aria-live="polite" to ensure the widest possible support.


3

For Deaf Users: Email and SMS will do. Technically they're not blind so they can read. You can also use facebook or other social networks for alternative contacts so you can message your users. Your suggestions: Both are good but it's also safe if you will make Email field required even if you already have, so you can confirm if the user didn't change their ...


0

You should always create a platform that has multiple notification options. You could send an E-mail to the registered user (As you suggested), and also, send them an SMS or Text message to the same number, which can be used as record for further referrals. This should cover the notification requirements. Make a contact number and E-mail address ...


-1

The second is right! The assistive machines will read the role="presentation" attribute of parent table but they will ignore it, and will continue referring to the second declaration, or vise-versa depending on the way they consume DOM - inside out or outside in.


-1

I agree with the comment above about creating a good typographic design and all your readers will benefit. My problem with removing italics is that in doing so you are also ignoring the standards set out for proper document creation. Italics are to be used when referencing titles of works, foreign words/technical terms/unfamiliar words (though you can also ...


0

This is a perfect example of the importance of including the user in the user experience design. The contributions from the experts on this site and very valuable and will help you a ton, but getting input from the actual users as early as possible in any design situation will highlight important details early and avoid you having to try and retro-design ...


13

My father has late-stage PD and after watching him use his Mac for the last 15 years here are some thoughts in no particular order: Assume the user can't use both hands or combinations of keys. My father uses his non-dominant hand with a track-ball because it shakes less, but has to use the keyboard and click with the same hand. Try that one out yourself ...


0

It could be useful to explore an alternative voice input. If a user has trouble pressing a control is there another way they could do it with voice? Could there a big voice activation control on each screen? I agree with another comment that it would be really useful to test the app with people with Parkinson's.


5

I think you should go a week or so using some of the peripherals that these patients would use. You probably know UX as you experience the web, but you should get to know the challenges that they face when they're not using a mouse and a screen. They might have a hard time reading on the screen because of the shaking, so maybe they use a screen reader with ...


28

People with Parkinson Disease (or PD as it's also known) need special considerations as you correctly figured. However, keep in mind that most of those considerations are covered by special peripherals rather than specific UI. As a matter of fact, just following common WAI- ARIA guidelines is more than enough. Keep in mind that, like many people with ...


0

I would give larger hit areas than we would for regular users as parkinson's patients experience tremors. Maybe try to simulate that with a shaking screen and try to use the interface yourself to experience how useable it in in that state. The best way would be to test out your interface on your target users and to adjustments based on your feedback.


3

Mouse-click is always better than mouse-hover, because mouse-click allows you to support all keyboard users, those who may or may not need accessibility support. It also helps you transition to touch-based devices like Tablets and Smartphones where you don't use a mouse, i.e. tap triggers the mouse-click. So benefits all round when you use mouse-click and ...


0

alt The a element can’t have an alt attribute. alt is for providing alternative text for an image that can’t be loaded/perceived, so it wouldn’t make sense to use it for a hyperlink. Attributes for a that can be relevant for accessibility (Leaving technical things like using the correct dir, or adjusting tabindex if needed, aside.) title For title, ...


1

What is shocking in your design is that 40% of the space is taken by action button and not by the main information. The buttons are taking to much space. Promote the content, not the tools. Some icons are very generic and don't need explanation. I don't speak Arabic but I can tell that the first button is "edit", second is "print", third "validate", fourth ...


2

The most common level of WCAG adherance is AA, which does not require some of the things you were likely initially turned off by. Using your example, WCAG 2.0 AA does require closed captioning on videos, but does not require a sign language interpretation. To learn more on your own, consider an online course. I can personally recommend the courses from Deque ...


2

You could have a "More details" button/link that opens a modal window with additional fields. download bmml source – Wireframes created with Balsamiq Mockups Clicking on "More details" would open a popup similar to the one below. download bmml source


8

Yes, the Equalities Act 2010 (previously the Disability Discrimination Act) is such a law in the UK. And it has been used before for prosecuting companies offering poor accessibility (generally for things like offers only being available to fully-sighted people who browse a website with mouse, so users with screenreaders, or only using keyboard can't ...


4

No, alts tags are invalid attributes on <a> tags (i.e. hyperlinks). W3 <a> tag specification : Global attributes href target download rel hreflang type and under "W3 Global Attributes" you get: accesskey class contenteditable dir hidden id lang spellcheck style tabindex title ...


0

Section 508 VPAT checklists are due for a refresh, because they are now very old, and will soon be adopting WCAG 2.0 to bring the USA in-line with the standards used by the rest of the world https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/ii-executive-summary


0

As some have already mentioned, WCAG is the one to look at. I've found this visual tool extremely helpful - keeps in focus some of the tasks you need to achieve depending on which level of WCAG you want to meet and breaks them on into the different disciplines responsible for actioning them (Dev, UX, etc) Also keep in mind WCAGs overall objectives - but ...


2

You mentioned you are a novice developer. In addition to the other great answers I want to answer on that perspective. HTML and CSS are designed with accessibility in mind. Making good use of them is the first step. It's not just about following W3C guidelines but also understanding them. Understand the semantics of HTML elements, learn about aria ...


2

Keep in mind that the best way to ensure that you meet accessibility requirements is not to simply run through a checklist of criteria that are mostly based on technical implementation details. WCAG 2.0 guidelines were very specific about doing 'human' testing to ensure that the site does more than just meeting technical specifications because it is only ...


9

WCAG2.0 is the currently generally-accepted standard for accessibility. Section 508 compliance checklists also exist (http://www.section508.gov/summary-section508-standards) but may be outdated: the original 508 guidelines are comparatively vague, and were written before e.g. screenreaders could interpret javascript so are more restrictive than necessary. ...



Top 50 recent answers are included