Skip to main content

Home/ Web Accessibility/ Group items tagged element

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

html5-boilerplate/css/main.css at master · h5bp/html5-boilerplate · GitHub - 0 views

github.com/...main.css

css html5 boilerplate screen reader reading usability webdesign accessibility

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • /* * Hide from both screenreaders and browsers: h5bp.com/u */.hidden {    display: none !important;    visibility: hidden;}/* * Hide only visually, but have it available for screenreaders: h5bp.com/v */.visuallyhidden {    border: 0;    clip: rect(0 0 0 0);    height: 1px;    margin: -1px;    overflow: hidden;    padding: 0;    position: absolute;    width: 1px;}/* * Extends the .visuallyhidden class to allow the element to be focusable * when navigated to via the keyboard: h5bp.com/p */.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus {    clip: auto;    height: auto;    margin: 0;    overflow: visible;    position: static;    width: auto;}/* * Hide visually and from screenreaders, but maintain layout */.invisible {    visibility: hidden;}
Vernon Fowler

WebAIM: Blog - 10 Easy Accessibility Tips Anyone Can Use - 0 views

webaim.org/...10-easy-accessibility-tips

accessibility html css tips and tricks

shared by Vernon Fowler on 13 May 13 - No Cached
  • add the appropriate landmark role attribute (role="main", role="navigation", or role="search". If your site uses HTML5 <main> or <nav>, add the role to these elements.
  • Sighted keyboard users generally navigate through the links and form fields on a web page using the Tab and Shift+Tab keys on the keyboard. To help ensure they can visually identify which link or form field they have navigated to, you can add the following to your CSS file: a:focus { outline:1px solid red; background:yellow; } The colors may need to be customized to fit your site design, but they should be fairly distinctive. To take this tip one step further, you can search your CSS files for a:hover and in each instance change it to a:hover, a:focus. This will ensure that keyboard users get the same visual highlighting when they navigate to items as mouse users get when they hover over an item.
  • Vernon Fowler on 13 May 13
     
    "Today is Global Accessibility Awareness Day (GAAD). To celebrate and to help promote accessibility, here are 10 simple accessibility tips that most anyone can implement today into their web site's HTML and CSS to make it more accessible."
Sandra Earl

Bruce Lawson's personal site  : Proposals for changes to lists in HTML 5 - 0 views

www.brucelawson.co.uk/...als-changes-to-lists-in-html-5

accessibility HTML5 lists development standards

shared by Sandra Earl on 12 Oct 10 - Cached
  • One of the things that have long irritated me about HTML is the restriction on what elements are allowed inside lists. The specs for both HTML 4 and 5 allow only li for ul, ol, and only dt and dd are allowed inside dl definition lists. I’d like to expand that to allow h1…h6, section and div.
  • Sandra Earl on 12 Oct 10
     
    Is this what we want to do with navbars?
Sandra Earl

WebAIM: Screen Reader Survey Results - 0 views

webaim.org/...screenreadersurvey

accessibility vision blindness screen reader WebAIM general FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • We received 1121 valid responses to the screen reader survey, which was conducted Dec. 2008 - Jan. 2009.
  • Skip to content22% Skip to main content28%
  • 33 respondents (2.9%) reported being both deaf and blind.
  • ...33 more annotations...
  • Please rate your computer proficiency Response% of Respondents Expert22% Advanced44% Intermediate27% Beginner8%
  • Please rate your screen reader proficiency Response% of Respondents Expert17% Advanced41% Intermediate32% Beginner9%
  • Screen Reader Usage
  • Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported. Individual versions of screen readers are not yet computed, but generally the majority of users are using the most up-to-date version of their screen reader.
  • How soon do you update your screen reader after a new version is released? Upgrade Window% of Respondents Immediately41% First 6 months25% 6-12 months9% 1-2 years9% 2-3 years4% 3+ years6% No response6%
  • How customized are your screen reader settings? (e.g., changed verbosity, installed scripts, etc.) Response% of Respondents A lot29% Somewhat40% Slightly21% Not at all7% No response4%
  • a lot or some customization was reported by only 27.6% of respondents with no disability versus 71.4% for those that reported blindness.
  • 78% of respondents reported using a screen reader on a desktop computer, 54% use a screen reader on a laptop, and 12% use a screen reader on a mobile phone.
  • No respondents who use screen readers for evaluation reported using a screen reader on a mobile device.
  • Which web browser(s) do you currently use with a screen reader? Browser% of Respondents IE633% IE768% IE82% Firefox39% Safari6%
  • Respondents with no disability were nearly twice as likely to list Firefox as blind respondents - 66% to 37%.
  • The percentage of Safari users is over double that of the overall population - this may be due in part to the fact that some in the Mac community actively solicited survey participation and encouraged respondents to indicate their Safari use, perhaps partially due to feeling snubbed because we didn't list them with IE and Firefox as direct choices.
  • When first accessing a new, unfamiliar home page, I'm most likely to... Response% of Respondents Read through the home page46% Navigate through or listen to the links on the page35% Use the Search to find what I'm looking for13% Look for a site map or site index3% No Response2%
  • Interestingly, the more proficient screen reader users are more likely to read through the home page and use links less often than less proficient screen reader users. This may be due to faster reading speeds for more experienced users. The home page strategies used were very similar regardless of proficiency, disability, or amount of screen reader use.
  • I use "skip to content" or "skip navigation" links... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10% No Response4%
  • Some questions were of a technical nature and we understand that many participants may not have been very technically savvy. Responses may also be based upon user experiences with web content that is generally inaccessible. We cannot help but wonder if responses may have been different if screen reader interactions with web content were typically very positive.
  • I use Access keys... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10%
  • I navigate by headings... Response% of Respondents Whenever they're available52% Often24%
  • 76% always or often navigating by headings when they are available.
  • I use site search functionality... Response% of Respondents Whenever it's available26% Often25% Sometimes31%
  • Find the word "Search"18% Jump to the first text/edit field on the page25%
  • Jump to the first form element in a page36%
  • Proficient screen reader users were more than twice as likely to jump directly to the form or text/edit field than less proficient users. Less proficient users were nearly three times more likely to use more manual methods (reading, tabbing, or finding) than more proficient users.
  • a majority of respondents seldom or never use site maps. There was no marked difference in the use of site maps across screen reader proficiency or disability. In general, it appears that site maps may be beneficial, but are not commonly accessed by screen reader users.
  • Text-only versions are always used by many and never used by many. As such, it is very difficult to interpret the value they have for screen reader users. More proficient screen reader users were much less likely to use text-only versions than less proficient users. This may suggest that proficient users employ sufficient techniques to render the main version acceptable to them. Or, it may suggest that proficient users do not gain value in using text-only versions, which are often less than optimal.
  • If content is identified as being "for screen reader users", how often do you use it? Response% of Respondents Whenever it's available38% Often15% Sometimes25% Seldom13%
  • A closer analysis, however, reveals that pop-up windows are reported as very difficult twice as often by less proficient screen reader users than with higher proficiency. Alternatively, more proficient users were three times more likely to indicate that pop-up windows are not at all difficult. This shows that less proficient screen reader users (which represent 41% of respondents) have more difficult experiences with pop-up windows.
  • Firefox users were much more likely to give a favorable response, perhaps a reflection of Firefox support for ARIA, etc. Evaluators and those without disabilities were nearly twice as likely to indicate that these applications are not very or not at all accessible than those that always use screen readers or have disabilities. This may suggest that these applications are actually more accessible than evaluators believe them to be, or alternatively, that screen reader users with disabilities are less knowledgeable about the true inaccessibility of these technologies.
  • 66% of evaluators preferred that the image be ignored, compared to only 28% of those that always user a screen reader. Similarly, 65% of those with no disability preferred that the image be ignored, compared to 29% of those with disabilities.
  • If a web page contains a photo of the White House, I prefer that the image be identified as... Response% of Respondents Photo of the White House80%
  • 69.4% of evaluators found them difficult compared to only 42.6% of those that always use a screen reader. Those with higher screen reader proficiency naturally found these links easier.
  • 71.5% of screen reader users reported that Flash is difficult
  • While the majority (58%) of users reported that frames are easy, those that are blind were 3 1/2 times more likely to indicate that they are easy than those with no disability. Similarly, those that always use a screen reader reported frames as easy nearly 3 times more often than evaluators. This perhaps suggests a misconception among those that do not have disabilities that frames are very inaccessible when in fact those with disabilities find them easy.
Vernon Fowler

Don't Use The Placeholder Attribute - Smashing Magazine - 0 views

www.smashingmagazine.com/...placeholder-attribute

inclusive input formdesign aria forms inclusivedesign hint accessibility form html

shared by Vernon Fowler on 27 Jun 18 - No Cached
  • To recap, the placeholder attribute: Can’t be automatically translated; Is oftentimes used in place of a label, locking out assistive technology; Can hide important information when content is entered; Can be too light-colored to be legible; Has limited styling options; May look like pre-filled information and be skipped over.
  • Move the placeholder content above the input, but below the label:
  • Development Here’s how to translate our designed example to code:
  • ...4 more annotations...
  • aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.
  • By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience.
  • The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.
  • Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content.
  • Vernon Fowler on 27 Jun 18
     
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
Vernon Fowler

Customise radio buttons without compromising accessibility - 0 views

www.chenhuijing.com/...out-compromising-accessibility

accessibility webdesign input buttons inclusivedesign

shared by Vernon Fowler on 16 Sep 18 - No Cached
  • go with option 3, a good ole’ opacity: 0 coupled with a position: absolute. Hidden but still focusable, well-supported across browsers. Just what we’re looking for.
  • opacity: 0
  • the label has to come after the input element in the source order
  • ...1 more annotation...
  • sad state of affairs when it comes to browser support for clip-path.
  • Vernon Fowler on 16 Sep 18
     
    "Customised radio buttons and checkboxes are a common design pattern found on the web, and it doesn't take too much to ensure that your beautifully designed toggles are still navigable via keyboard."
Vernon Fowler

Prettier Accessible Forms · An A List Apart Article - 0 views

alistapart.com/...prettyaccessibleforms

accessibility formdesign forms screenreaders

shared by Vernon Fowler on 09 Feb 19 - No Cached
  • The fieldset element allows us to group form controls into logical, related “chunks.” legend then allows us to add a caption to that fieldset, which helps users understand the context of the form controls contained within that fieldset. In some screen readers, the legend is associated with each form control within a fieldset and is read out after each tab of the keyboard, so that a particular control can always be referenced back to its legend.
  • Vernon Fowler on 09 Feb 19
     
    "The most important part of a form is the HTML we use to build it. Fortunately, HTML gives us a nice assortment of tags to build our forms in an accessible way. These are fieldset, legend, and label."
Vernon Fowler

WebAIM: Usable and Accessible Form Validation and Error Recovery - 0 views

webaim.org/...formvalidation

validation accessibility usability forms errors aria

shared by Vernon Fowler on 16 Mar 17 - No Cached
  • Errors on top
  • As one would guess, the "Errors on top" approach causes the error message to appear before the form. When presented, focus should generally be set directly to this error message. This allows screen reader and keyboard users to immediately access the error message without having to find it amongst the rest of the page contents. The message should also be visually apparent. Focus can be set to the message with client-side scripting using JavaScript focus() or similar, or the server-generated page can include an anchor name in the URI (e.g., http://myserver.com/form.php#errormessage) which will set focus directly to a named anchor or element id located at the beginning of the feedback message.
  • also helpful to inform the user as to the number of errors that were detected
  • ...2 more annotations...
  • provide a link within the error message that will set focus to the appropriate form control
  • Regardless of the mechanism used to identify and recover from form errors, aria-invalid="true" should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being "invalid" or in need of attention.
Vernon Fowler

WebAIM: Keyboard Accessibility - 0 views

webaim.org/keyboard

accessibility testing keyboard

shared by Vernon Fowler on 02 Jun 17 - No Cached
  • Long lists of links or other navigable items may pose a burden for keyboard-only users.
  • The following best practices can facilitate efficient keyboard navigation: Provide a "skip to main content" link on the page. Use a proper heading structure. Provide ARIA landmarks or HTML5 structural elements (<main>, <nav>, etc.)
  • Vernon Fowler on 02 Jun 17
     
    "when testing with a keyboard, you are not just trying to interact with the page successfully, you also want to ensure all interactions are predictable. This requires an understanding of common keyboard interactions."
Vernon Fowler

Don't Rely on Default Browser Error Messages - Intopia - 0 views

intopia.digital/...default-browser-error-messages

accessibility forms validation HTML5

shared by Vernon Fowler on 06 Feb 19 - No Cached
  • Another issue is that the messages are temporary. As soon as you put focus on the input with mouse, keyboard or touch, the message disappears. People with cognitive impairments will find it difficult to use these, and I think anyone trying to fill in the form while they’re distracted will have trouble as well. People who rely on the keyboard for navigation (which includes both sighted users and screen reader users) will also lose these messages as they move around the form.
  • If you’re confident of your error messages, you can remove the browser validation by adding the novalidate attribute to the wrapping form element, like this: <form novalidate>...</form>
  • You can style this with CSS, using the :valid and :invalid pseudo-classes
  • ...2 more annotations...
  • Only the first error is noted with a message.
  • The rest rely on a change of border colour, which is, again, not evident to screen reader users.
  • Vernon Fowler on 06 Feb 19
     
    "When I found out the major browsers were beginning to include error validation into their support for forms, I was pretty excited. Form validation is always a fiddly part of accessibility, so I'm always looking out for ways to make it easier for developers to do properly. I read MDN's form data validation tutorial and a CSS Tricks article on client-side form validation and immediately made some test forms. Sadly, I was disappointed with the results. The default error validation in browsers is almost completely inaccessible. I was hoping we'd get default "you've forgotten to fill this in" messages that could be customised. I might have been a bit too optimistic! Validation at the browser level has many of the same issues we find at the website level."
‹ Previous 21 - 35 of 35
Showing 20▼ items per page