Skip to main content

Home/ Web Accessibility/ Group items tagged search

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

WebAIM: Appropriate use of alternative text - 0 views

webaim.org/...alttext

accessibility standards reading usability alternative text

shared by Vernon Fowler on 13 Aug 12 - No Cached
  • It is read by screen readers in place of images allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities. It is displayed in place of the image in user agents (browsers) that don't support the display of images or when the user has chosen not to view images. It provides a semantic meaning and description to images which can be read by search engines or be used to later determine the content of the image from page context alone.
  • The first step when determining appropriate alternative text for an image is to decide if the image presents content and if the image has a function. In most cases, an image will only have a function if it is contained within a link.
  • NOT use the phrases "image of ..." or "graphic of ..." to describe the image.
  • ...14 more annotations...
  • NOT be redundant or provide the exact same information as text within the context of the image.
  • (no alt attribute) is never the right choice
  • When possible, avoid using "link to" or "click this image" or similar wording in the alt attribute. Links are identified as links by screen readers and should be visually apparent to sighted users.
  • Decorative images do not present important content, are used for layout or non-informative purposes, and do not appear within a link. In almost all cases, spacer and decorative images should have null alt text (alt="").
  • Option C (alt="") would be most appropriate in this case because the image does not convey relevant or important content.
  • Form image buttons must have an alt attribute that describes the function of the button. Image buttons are often used to provide a more visually appealing or a smaller version of the standard form buttons. The alternative text should describe what the button will do when selected, such as "Search", "Submit", "Register", "Place your order", etc. For instance, <input type="image" alt="Submit Search"> might be appropriate for an image button on a site search form.
  • text must be provided to the user which presents the CONTENT and FUNCTION of the images within your web content
  • In many cases, images may be given an empty or null alt attribute (e.g., alt="").
  • Option B is the best choice - it clearly provides the content that is being presented by the image - that the link is to a PDF file.
  • Because this is fairly standard practice, providing alternative text for the image, such as your company name (alt="Acme Company), will usually suffice.
  • It is important to note here that if the icon itself were the link to the document, the alternative text should provide a full alternative of the content and function of the link/image combination. Something like, "Download the employment application in PDF format".
  • Alternative text should: presents the CONTENT and FUNCTION of the image. be succinct.
  • Alternative text should not: be redundant (be the same as adjacent or body text). use the phrases "image of…" or "graphic of…".
  • Alt text of a functional image (e.g., an image within a link) should describe the function as well as the content.
Arthur Cane

Excellent SEO Service That Last - 1 views

I have been working with Syntactics Inc. for five years now, and I have entrusted my online business to them for that long because I found their services really excellent. In fact, for that five...

seo services

started by Arthur Cane on 27 Dec 11 no follow-up yet
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

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."
Vernon Fowler

In Search Of The Perfect CAPTCHA | Smashing Coding - 0 views

coding.smashingmagazine.com/...-search-of-the-perfect-captcha

captcha development accessibility web webdesign usability

shared by Vernon Fowler on 28 Apr 13 - No Cached
  • Try the honeypot method or another that is invisible to users. Some could potentially be bypassed, but their presence is often enough to thwart automated efforts.
Sandra Earl

WebAIM: Accessibility of Rich Internet Applications - 0 views

webaim.org/aria

accessibility ARIA WebAIM

shared by Sandra Earl on 12 Oct 10 - Cached
  • WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content.
  • ARIA provides accessible interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), content roles for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more.
  • WAI-ARIA provides the ability for developers to specify roles for document areas (and many other things).
  • ...2 more annotations...
  • accessibility issues with rich internet applications can be characterized as: Providing the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.) Maintaining accessibility of content that is dynamic and may change within the page (e.g., AJAX content updates) Allowing certain non-focusable page elements to receive keyboard focus (e.g., setting focus to an error message within the page) Providing keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)
  • ARIA is being implemented into many scripting libraries (such as jQuery, Dojo, YUI, and GWT). While developers can certainly implement ARIA into their advanced widgets and applications, using ARIA-supported libraries greatly simplifies the process of providing this level of accessibility.
Vernon Fowler

WebAIM: Semantic Structure - 0 views

webaim.org/...semanticstructure

semantic structure headings lists webdesign content usability accessibility markup

shared by Vernon Fowler on 18 Feb 14 - No Cached
  • Their sole purpose is to designate a hierarchy of headline importance, so that both human readers and automated search engines can look at a document and easily determine its information structure.
Sandra Earl

Digital Web Magazine - Understanding Disabilities when Designing a Website - 0 views

www.digital-web.com/...ities_when_designing_a_website

accessibility design standards general development FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • In the UK In the US 2m people have a vision impairment3 10m people have a vision impairment4 8.2m people have mild to moderate deafness5, 688,000 people have severe to profound deafness6 28m people have a hearing impairment7 3.4m people have a physical disability8 8m people have a physical disability9 1.5m people have a learning disability10 6.8m people have a learning disability11 6m people have dyslexia12 25m people have dyslexia13
  • Most people who are blind will rely on screen reading software such as
  • JAWS or Windows-Eyes
  • ...41 more annotations...
  • refreshable Braille device which converts the text on the website into Braille.
  • Place form instructions before the form field
  • To improve accessibility and usability for screen reader users, form field requirements must be placed before the form field itself.
  • Provide a ‘skip to main content’ link Screen reader users benefit from a ‘skip to main content’ link as it enables them to jump over lengthy navigation to the main content of the web page, reducing the amount of content they have to listen to.
  • Ensure link text is descriptive Screen reader users using software such as JAWS can listen to the links on a web page through functionality known as a links list. If link text is not descriptive—solely using phrases such as “click here” or “more information”, for example—there is no way for screen reader users to determine where the link will take them.
  • Provide descriptive web page titles The first piece of information a screen reader user will listen to when they open a web page is the <title> assigned to the page. It is important, therefore, to use a title which reflects the content of the web page.
  • Provide descriptive headings It is important to provide descriptive headings
  • Screen reader users often listen to headings out of context from the main content
  • Provide audio descriptions and transcripts of video content Screen reader users depend on audio descriptions to provide additional information about important visual content displayed within a video.
  • Transcripts are written accounts of the video or audio content and can include additional information such as comments and descriptions
  • screen reader users cannot use a mouse
  • People with low vision will tend to use magnification software to make reading a website easier. Depending on the severity of their vision impairment, these users may combine magnification and screen reading software by using software products such as Supernova or ZoomText. For milder vision impairments, users may just increase the default size of text within their browser settings or change the colors to make the content more comfortable to read.
  • Avoid using images of text
  • Ensure text can be resized
  • Place key information in specific locations of the screen
  • ebsite search functionality is often located in the top-right corner of the web page
  • Juicy Studio color contrast analyzer.
  • it is possible to determine whether the colors chosen meet the minimum requirements specified in the WCAG Guidelines.
  • People with a hearing impairment tend not to use assistive software to improve their web browsing experience. Instead, they rely on the website being accessible by providing any audio content in alternative formats, such as captioning or transcripts.
  • By making audio content accessible for users with a hearing impairment, it also makes the content accessible for other users who find themselves in an environment where audio cannot be heard.
  • library with the sound turned down; they may be in a noisy environment where it is difficult to hear the audio; or they may be using a computer without speakers.
  • Provide captions for any video content
  • Provide transcripts of the spoken audio Where content is spoken without video, such as in a podcast, it is important to provide a transcript. It is recommended that the transcript be provided in plain accessible HTML to allow access by the widest possible audience, as opposed to a Microsoft Word or Adobe PDF document.
  • Physical disabilities range in severity from those who are temporarily disabled, for example having a broken arm, to those who are quadriplegic and have no use of any limbs. Depending on the severity of the physical disability, these users may access websites through voice recognition software such as Dragon Naturally Speaking.
  • However, what all users with a physical disability have in common is limited or no ability to use a mouse. This means that content within the website that requires a mouse click or fine motor control cannot be accessed by these users.
  • Ensure all content can be accessed via the keyboard
  • Users with a physical disability will have limited or no ability to use a mouse and as such will navigate websites using the keyboard.
  • Provide a focus state for links
  • Provide visible skip links Skip links are links that become visible when they receive focus, and are helpful for users with a physical disability. Keyboard users must tab through the web page to reach the particular link they are interested in—skip links allow lengthy navigation to be bypassed and reduce the number of key presses required to activate links in the main content.
  • Avoid moving targets Avoid using moving targets such as tickers, as users with a physical disability can find them very difficult to use.
  • Provide large clickable areas
  • provide sufficient whitespace between links
  • People with a cognitive or learning disability may have difficulties with memory, problem solving, perception, and conceptualization. In addition, people with a learning disability may have issues with reading and comprehension such as dyslexia.
  • To enhance the usability of the website for these users it is important that content is written in plain English, page layouts are simple in design, navigation is clear and consistent and there is no moving content to impede comprehension.
  • Provide the same look and feel throughout all pages of the website. Ensure that the navigation and main content are located in the same area of every page. Additionally, consider color coding different sections within the website. Users with cognitive or learning disabilities tend to find it easier to navigate around sections which are color coded.
  • Provide a site map A site map will enable users with a cognitive or learning disability to have a clear idea of the breadth of content contained within the website. The site map also enables users to directly access any page on the website, and helps if the user becomes lost.
  • Use a resizable sans-serif font which is left-aligned To increase readability for users with a cognitive or learning disability, use a sans-serif font which can be resized. Additionally, left-align content—justified text is more difficult to read due to the uneven spacing between words. Italicized and capitalized text should also be kept to a minimum to aid readability.
  • Provide helpful error messages
  • Offer speech output Organizations such as Browse Aloud and Textic enable content from a website to be spoken when highlighting the words on a web page. Offering this functionality is especially helpful for users who find it difficult to read large amounts of text.
  • Provide an Easy Read Version Consider providing an ‘easy read’ version of complex content. This combines plain text with images to aid understanding of the information. For an example of an easy read document see the Department of Health’s Making Lives Better for People with a Learning Disability.
  • Provide different color schemes People with cognitive or learning disabilities may benefit from different color scheme options. It is helpful if an easy read scheme such as a lemon background with dark text, and a hi-viz scheme such as a black background with yellow text, are provided.
Vernon Fowler

Bruce Lawson's personal site  : The practical value of semantic HTML - 0 views

www.brucelawson.co.uk/...actical-value-of-semantic-html

accessibility html mobile navigation

shared by Vernon Fowler on 25 Feb 19 - No Cached
  • styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
  • If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.
  • Apple WatchOS also optimises display of items wrapped in <figure> elements
  • ...4 more annotations...
  • First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
  • unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
  • By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users.
  • Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
Vernon Fowler

Breadcrumbs: 11 Design Guidelines for Desktop and Mobile - 0 views

www.nngroup.com/...breadcrumbs

navigation mobile

shared by Vernon Fowler on 18 Jul 19 - No Cached
  • the breadcrumb corresponding to the current page should not be a link. You should never have a link that does nothing. The last breadcrumb (denoting the current page) should not be a link.
    • Vernon Fowler
      Vernon Fowler on 18 Jul 19
       
      The breadcrumb denoting the current page SHOULD be a link and differentiated from others via mechanisms such as aria-current="page" See https://scottaohara.github.io/a11y_breadcrumbs/ for this pattern.
    • Vernon Fowler
      Vernon Fowler on 18 Jul 19
       
      The breadcrumb denoting the current page SHOULD be a link and differentiated from others via mechanisms such as aria-current="page" See https://scottaohara.github.io/a11y_breadcrumbs/ for this pattern.
  • Include the current page as the last item in the breadcrumb trail.
  • Breadcrumb trails should start with a link to the homepage.
  • ...14 more annotations...
  • Breadcrumbs aren’t necessary (or useful) for sites with flat hierarchies that are only 1 or 2 levels deep, or sites that are linear in structure.
  • Unfortunately, on mobile, the cost of using breadcrumbs can quickly overwhelm the benefits. Don’t use breadcrumbs that wrap to multiple lines.
  • Don’t use breadcrumbs that are too small or too crowded together.
  • Consider shortening the breadcrumb trail to include only the last level(s).
  • The Oregon state government website includes a breadcrumb trail, but omits a link to the homepage. However, in this case this is acceptable, as the site also includes a Home link in the global navigation
  • duplicating the Home link in both the global navigation and the breadcrumb trail is not recommended — one or the other is fine
  • This site’s structure is nonhierarchical, and so there is no need (or value) in including a breadcrumb trail.
  • MIT’s main website has a flat hierarchy, with only 1 page in each section. While it features a breadcrumb at the top of the page, this breadcrumb isn’t necessary. In the main navigation, the location of the page is highlighted.
  • Breadcrumbs should include only site pages, not logical categories in your IA.
  • The link to the parent page is a dropdown menu, with the current page’s siblings (bottom image). A better design would  have a separate UI for the local navigation, to enable users to travel to lateral pages in the current section of the site.
  • Breadcrumbs should not replace the global navigation bar or the local navigation within a section.
  • Breadcrumbs augment but do not replace those main forms of navigation.
  • when they skip some of these levels (for example, because they arrived to the site by clicking on an external link such as a search-engine result), breadcrumbs orient them and help them find their way to other, possibly more relevant, pages.
  • In this example, the home page and current page are omitted from the breadcrumb trail, which is not recommended.
1 - 11 of 11
Showing 20▼ items per page