Skip to main content

Home/ Web Accessibility/ Group items tagged interface

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

WebAIM: Accessibility of AJAX Applications - Accessibility Issues - 0 views

webaim.org/ajax

accessibility AJAX ARIA WebAIM

shared by Sandra Earl on 12 Oct 10 - Cached
  • AJAX is
  • a smorgasbord of web technologies put together to allow dynamic client-server interactions to occur in web applications without requiring pages to reload or refresh.
  • AJAX uses the following:
  • ...13 more annotations...
  • The XHTML and CSS elements can be dynamically modified to display new information or styling. These changes are typically done using the Document Object Model.
  • XHTML (or HTML) and CSS to create an interface and visually style information.
  • JavaScript is used to manipulate the interface elements and is also used to establish a communication with a web server through XMLHttpRequest. This allows data (typically in XML format) to be transmitted between the client and the web server without requiring page reloads or refreshes.
  • standard type of client-server interaction
  • A web page interface is presented. User information is collected (via forms, links, etc.). The user submits information (submits form, activates link, etc.). The server processes submitted information. A new web page interface is sent to the user.
  • With AJAX, all of these steps can be handled in one interface.
  • The types of web applications and interactions allowed by using AJAX has given rise to the term "Web 2.0"
  • AJAX allows feature-rich, dynamic web applications which use server-side processing without requiring the traditional "submit data — retrieve web page"
  • allows more streamlined applications that require less processing and data transmission
  • higher levels of interactivity
  • current solution to these problems is to either provide a non-AJAX alternative to your application or to allow your AJAX application to continue to function if JavaScript and XMLHttpRequest are not supported. Such a requirement may be very difficult to achieve
  • Another issue with AJAX is how the application interface is updated. When updates to the interface occur, it may not be visually apparent that a change has occurred. The problem is even more troublesome for screen reader users. Screen readers typically read in a linear fashion. When changes happen in the interface, the screen reader user may not be aware of the change and the new content will likely not be read.
  • to allow dynamic interface changes to be accessible, the application must alert the user that a change has occurred, allow direct access to the new content, and then allow continued functionality of the web application. This process, while difficult to achieve, especially for screen reader users, is possible to achieve in many AJAX applications.
Vernon Fowler

Introduction to Understanding WCAG 2.0 | Understanding WCAG 2.0 - 0 views

www.w3.org/...intro.html

WCAG accessibility web content standards

shared by Vernon Fowler on 09 Mar 16 - No Cached
  • Perceivable - Information and user interface components must be presentable to users in ways they can perceive.This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)Operable - User interface components and navigation must be operable.This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
  • users must be able to understand the information as well as the operation of the user interface
  • robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies
  • Vernon Fowler on 09 Mar 16
     
    "The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content."
Vernon Fowler

HTML5 accessibility - 0 views

www.html5accessibility.com

accessibility html5 browser development resources screenreaders web webstandards for:@twitter reference

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • Vernon Fowler on 24 Nov 12
     
    This site is a resource to provide information about which HTML5 user interface features are accessibility supported in browsers, making them usable by people who rely upon assistive technology (AT) to use the web.
Vernon Fowler

HTML_CodeSniffer - 0 views

squizlabs.github.io/HTML_CodeSniffer

accessibility bookmarklet tools html WCAG wcag2

shared by Vernon Fowler on 16 Feb 14 - No Cached
  • Vernon Fowler on 16 Feb 14
     
    HTML_CodeSniffer is a client-side script that checks HTML source code and detects violations of a defined coding standard. HTML_CodeSniffer is written entirely in JavaScript, does not require any server-side processing and can be extended by developers to enforce custom coding standards by creating your own "sniffs". To get you started, HTML_CodeSniffer comes with standards that enforce the three conformance levels of the Web Content Accessibility Guidelines (WCAG) 2.0, and the web-related components of the U.S. "Section 508" legislation. An auditor interface is provided by a bookmarklet to let you try out these accessibility checks on any web page.
Vernon Fowler

5 Ways to Offer a Better UX for Disabled Users - 0 views

www.sitepoint.com/offer-better-ux-disabled-users

accessibility research empathy colour typography video captioning webdesign

shared by Vernon Fowler on 08 Mar 16 - No Cached
  • Vernon Fowler on 08 Mar 16
     
    Empathy is unrivalled as a skill a user interface designer should have. Walking in somebody else's shoes (or seeing through their eyes may be a better metaphor), can be a temporary replacement for having a user/tester at hand. Let's take a look at some disabilities that we so often forget.
Vernon Fowler

Inclusively Hidden | scottohara.me - 0 views

www.scottohara.me/...inclusively-hidden.html

accessibility inclusivedesign screenreaders

shared by Vernon Fowler on 02 Oct 18 - No Cached
  • sometimes content is for decorative purposes only, and it would be optimal to not announce this content to assistive technology.
  • don’t use aria-hidden on focusable content
  • Purposefully Hidden from Assistive Technology
  • ...1 more annotation...
  • using aria-hidden to hide content specifically from screen readers
  • Vernon Fowler on 02 Oct 18
     
    There are various techniques to visually hide content in our web interfaces, but are you aware of the different effects they have on the accessibility of that content? While it would be nice if there was a single, native, solution for hiding content, there are contextual benefits to the various techniques at our disposal. Since there have been many articles already written about these techniques, over the many years they've been in use, the focus of this article will be to highlight the ones that are most appropriate for modern web development. We won't just look at the code behind each of these techniques, instead we'll focus on why each technique has its place, using practical examples to demonstrate their purposes. But before we talk about how to hide content we should ask ourselves a question… Why are we hiding content?
Vernon Fowler

Understanding Success Criterion 2.4.7: Focus Visible - 0 views

www.w3.org/...focus-visible.html

accessibility focus

shared by Vernon Fowler on 01 Oct 19 - No Cached
  • Vernon Fowler on 01 Oct 19
     
    "Success Criterion 2.4.7 Focus Visible (Level AA): Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."
Vernon Fowler

A List Apart: Articles: Now You See Me - 0 views

www.alistapart.com/...now-you-see-me

css webdesign accessibility usability content javascript class

shared by Vernon Fowler on 28 Oct 12 - No Cached
  • visibility: hidden; Element is hidden from view, but is not removed from the normal flow (i.e., it still takes up the space it normally would) Content is ignored by screen readers display: none; Element is removed from the normal flow and hidden; the space it occupied is collapsed Content is ignored by screen readers height: 0; width: 0; overflow: hidden; Element is collapsed and contents are hidden Content is ignored by screen readers
  • if you want to ensure users have access to content (even if it isn’t displayed visually in the current interface), the final option (positioning content offscreen) is really the way to go.
  • Screen readers have access to the content
  • ...6 more annotations...
  • position: absolute; left: -999em;
  • but links may “focus” oddly and negative indent may not prove long enough to fully hide content
  • limited to text and inline elements
  • Content is removed from the normal flow and shifted off the left-hand edge; the space it occupied is collapsed
    • Vernon Fowler
      Vernon Fowler on 17 Mar 13
       
      This is usually my desired effect.
  • If you don’t want your hidden content to be read by a screen reader, those defaults may work for you
  • how profoundly your choice of hiding mechanism can influence the accessibility of your content to assistive technologies like screen readers
Sandra Earl

Forget WYSIWYG editors - use WYSIWYM instead | 456 Berea Street - 0 views

www.456bereastreet.com/...yg_editors_use_wysiwym_instead

accessibility WYSIWYG

shared by Sandra Earl on 12 Oct 10 - Cached
  • A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.
  • Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.
  • That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.
  • ...4 more annotations...
  • Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.
  • But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.
  • From the WYMeditor site: Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.
  • There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed: Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables. Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database. Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.
Sandra Earl

Introduction to screen readers and screen magnifiers | 456 Berea Street - 0 views

www.456bereastreet.com/..._readers_and_screen_magnifiers

accessibility screen reader general resources FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • And that leads me to three great videos posted on the Yahoo! User Interface Blog: In Introduction to Screen Readers, Yahoo! engineer Victor Tsaran talks about who will be likely to use a screen reader, how screen readers work, and how they can be used to interact with the computer desktop and to browse web sites. In Introduction to Screen Magnifiers, Karo Caran shows how the screen magnifier ZoomText is used to make the computer desktop and web sites readable to people with reduced vision. And finally, in From the Mouth of a Screenreader, Doug Geoffray from GW Micro (Window-Eyes vendor) talks about the history of screen reading software and how they analyse what is displayed on the screen in order to speak it to the user.
Sandra Earl

YUI Theater - Victor Tsaran: "Introduction to Screen Readers" » Yahoo! User I... - 0 views

yuiblog.com/...video-intro-to-screenreaders

accessibility screen reader general multimedia FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • YUI Theater’s newest video is a 27 minute Introduction to Screen Readers by Victor Tsaran, an engineer here at Yahoo! and our Program Manager for Accessibility.
Sandra Earl

YUI Theater - Karo Caran and Victor Tsaran: "Introduction to Screen Magnifier... - 0 views

yuiblog.com/...deo-intro-to-screen-magnifiers

accessibility screen magnifiers general multimedia FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • With the goal of better understanding how people interact with the Web via various types of Assistive Technology (AT) — and what that might mean for developers and designers — Karo Caran takes us on a 16 minute overview of screen magnification software (in this case ZoomText) and how it is used by partially-sighted users to interact with the Web. Karo shows you the basic toolkit and then applies those tools to some typical web sites to give you some perspective on how she uses magnification software while she browses the web.
Sandra Earl

YUI Theater - Doug Geoffray: "From the Mouth of a Screenreader" » Yahoo! User... - 0 views

yuiblog.com/...video-geoffray

accessibility screen reader general multimedia FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • he context is important for us on the frontend as we begin to confront the same challenges that desktop software developers have been addressing for many years.
  • Doug been a touchstone for us at YUI in the research and development of our Menu Control, a project that is helping us to lay a foundation for what is possible in terms of DHTML accessibility as YUI evolves.
Vernon Fowler

Using ARIA - 0 views

w3c.github.io/using-aria

accessibility aria

shared by Vernon Fowler on 31 Oct 18 - No Cached
  • aria-describedby with single or multiple id references
  • aria-label and aria-labelledby have similar behaviour in screen readers and the Accessibility API, but aria-label should be reserved for when there is no visible text on the page to reference or when keeping track of id values would be too difficult.
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

Links that don't go anywhere should be buttons | Christian Heilmann - 0 views

christianheilmann.com/...-go-anywhere-should-be-buttons

interface buttons accessibility patterns

shared by Vernon Fowler on 17 Feb 19 - No Cached
  • there is no point in confusing your users with a link that goes nowhere and won’t open anything in another tab. Use a button and you won’t promise any functionality you don’t have.
  • links keep getting used for functionality that doesn’t go anywhere on the web or in the document
1 - 19 of 19
Showing 20▼ items per page