Skip to main content

Home/ Web Accessibility/ Group items tagged components

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

Tim Anderson's ITWriting - Tech writing blog » Adobe AIR: 10 reasons to love ... - 0 views

www.itwriting.com/...-it-10-reasons-to-hate-it.html

accessibility adobe air online help

shared by Sandra Earl on 12 Oct 10 - Cached
  • 3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.
  • 7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.
  • 4. Proprietary technology. AIR applications depend on Adobe’s runtime.
  • ...3 more annotations...
  • 6. No model for commercial components. It is not clear to me how a component vendor could sell an AIR component while protecting it from unlicensed deployment. This may limit the availability of 3rd party components, with a corresponding impact on productivity.
  • 7. Schizophrenic development model. AIR supports either Flex development, or HTML applications which run in WebKit. The ugly side of this flexibility is that there are two SDKs, even two JavaScript virtual machines with different capabilities and characteristics. While it is nice to have a way to render HTML, I am not convinced that the web application model is worth it, given the complications it causes. After all, web applications run perfectly well in the browser.
  • Lack of UI standards may lead to annoying inconsistencies between AIR applications. We are used to this on the Web; now it is coming to the desktop as well.
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

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

WebAIM: Keyboard Accessibility - Tabindex - 0 views

webaim.org/...tabindex

DIG252 keyboard accessibility navigation focus html

shared by Vernon Fowler on 20 Aug 14 - No Cached
  • tabindex="0" and tabindex="-1" have special meaning and provide distinct functionality in HTML. A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus. Of course one should generally use links and form controls for all interactive elements, but this does allow other elements to be focusable and trigger interaction.
  • A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus.
  • A tabindex="-1" value removes the element from the default navigation flow (i.e., a user cannot tab to it), but it allows it to receive programmatic focus, meaning focus can be set to it from a link or with scripting. This can be very useful for elements that should not be tabbed to, but that may need to have focus set to them. A good example is a modal dialog window - when opened, focus should be set to the dialog so a screen reader will begin reading and the keyboard will begin navigating within the dialog. Because the dialog (probably just a <div> element) is not focusable by default, assigning it tabindex="-1" allows focus to be set to it with scripting when it is presented.
  • ...1 more annotation...
  • A value of -1 can also be useful in complex widgets and menus that utilize arrow keys or other shortcut keys to ensure that only one element within the widget is navigable with the tab key, but still allow focus to be set on other components within the widget.
1 - 5 of 5
Showing 20▼ items per page