サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
新内閣発足
www.tpgi.com
A well-designed user interface (UI) should clearly identify important content and controls. Often people correlate this to using prominent visual cues to help guide individuals through a task or point them to necessary information. However, what may be visually apparent to some could be misunderstood or completely passed over by others. If someone uses assistive technology to navigate an interface
Modal dialogs continue to be troublesome UI components all across the web. Putting aside the fact they are often misused and thrust on users in a manner that interrupts their current task (asking me to sign up for your newsletter, while I’m in the middle of reading an article, is not cool), even appropriately used modals often lack considerations for accessibility. While poor modal dialog UX is st
Updated March 2023 Clearly visible focus styles are important for sighted keyboard users. However, these focus styles can often be undesirable when they are applied as a result of a mouse/pointer interaction. A classic example of this are buttons which trigger a particular action on a page, such as advancing a carousel. While it is important that a keyboard user is able to see when their focus is
The CSS display properties are powerful. You can change the visual display of elements to match your desired styling, but sometimes doing this can have an unintended effect of nuking the semantics of the elements, as conveyed to screen reading software, in the browser accessibility tree. Screen readers and other assistive tech, in general, do not have direct access to the HTML DOM, they are provid
The TPGi Mobile Accessibility Testing for Android and iOS (PDF, 2.6MB) is a free accessible PDF outlining how to test native apps and the web for accessibility on Android and iOS. It provides an overview of accessibility settings, how to use them and common testing tools. Instructions on how to test content are provided for Android Talkback, iOS VoiceOver, zoom and switch settings. Also included a
The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility ev
The other day, in relation to a github comment, I was asked by my friend Mike[tm]Smith “Can alt have line breaks in it or does that do weird things to assistive technologies like screen readers?”. I did some quick testing. What I found was that line breaks in alt attribute text, has a few suboptimal effects, dependent on browser and screen reader used. The noted UX effects of line breaks (limited
Testing the Flipboard site on a mobile device such as an iPhone, quickly reveals that the content is not available to screen reader users. This is because the content is painted onto a canvas element using React Canvas. The words, structure and UI are all visual, there is nothing but pixels. Reading the React Canvas documentation. It states: Accessibility This area needs further exploration. Using
Updated 1st Feb 2016. When you test your website with a screen reader there are a few basic commands you should know. Just remember not to make design decisions based only on your tests. Even with these useful screen reader commands, you won’t experience things in the same way as a person who uses a screen reader all the time. There isn’t much information available about the platforms, devices and
Jaws 15 and Internet Explorer 10 is the best combination at present, although nested SVG images are not well supported. NVDA and Internet Explorer present the role, title and desc, but support is erratic with multiple images announced and repetition of the title and desc. In all other browser/screen reader combinations the SVG is ignored. ARIA enhanced SVG accessibility It is possible to enhance t
ARIA is a set of attributes that can be added to HTML elements (and other markup languages) to communicate accessibility role, state, name and properties which are exposed by browsers via platform accessibility APIs. This provides a common, interoperable method of relaying the information to assistive technologies. That’s it. It is the same method used by browsers to convey the inbuilt (or default
Adding ARIA landmarks to your existing site, or to a site you are developing, provides useful global navigation features and aids understanding of content structure for users. Over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics. There is widespread support for ARIA landmarks in browsers and screen readers. H
I am in the process of updating HTML5Accessibility.com (ETA mid September) to take into account the changes in accessibility implementation support in the latest browser versions. I have decided not to update support information for Safari/Webkit on Windows and Opera on Windows or Mac as these browser/OS combinations show no sign of active HTML accessibility implementation support. If and when t
ARIA role=alert is supported across modern browsers and assistive technology, but implementation in browsers differ, which can lead to role=alert appearing to be unsupported. role=alert what does it do? When an element has a role=alert is displayed it triggers an alert event in the browsers implemented accessibility APIs. This is picked up by assistive technology (AT) and the text content of the e
Latest Update: The state of hidden content support in 2016 As a developer and also a consultant advising developers on how to develop accessible content, it is important to have and provide up to date and practical knowledge about robust development techniques. A recent question on Stack Overflow got me thinking: What is the best method for hiding content for all users? For hiding content for some
It is conforming in HTML5 for links to include block level elements such as headings and paragraphs, this was forbidden in previous versions of HTML. A recent article by @feather concludes that the inclusion of block level elements inside a link causes some Assistive Technology (AT) to misbehave. Block Links in HTML5 The HTML5 specification says: The a element may be wrapped around entire paragrap
I tweeted the other day, suggesting people switch to the HTML5 doctype as the use of ARIA is conforming in HTML5. As things stand, if ARIA roles, states and properties are used on HTML elements with a doctype other than <!DOCTYPE html> a developer will get unhelpful error messages when using an HTML validator simply because the DOCTYPE they are using does not recognise ARIA attributes as valid. Th
A recent decision by the W3C HTML working group has caused much discussion and some consternation within the accessibility community and wider web development community. If you want change get involved! As per W3C policy the decision made by the HTML working group is not the end of the road. It can be re-opened or a formal objection can be lodged. Both of these options are being actively pursued b
Many User interface widgets can be developed using HTML, CSS and JavaScript, in some cases developers build custom versions of native HTML controls because they cannot achieve the exact look and feel or behaviour they desire with a native control. Where ever possible it is recommended that native HTML controls be used over custom controls as their accessibility support is likely to be more robust
Upcoming Webinar: October 1 at 12 PM ET. Agile and Accessible User Experiences with AT User Flow TestingRegister Now
The latest in accessibility law, strategy, program management, and news, as well as upcoming events, and articles on web development issues, techniques, design patterns, auditing, WCAG, and resources of a technical nature. TPGi blog articles are grouped into two main categories:
Upcoming Webinar: September 10 at 11 AM ET. Translating Digital Accessibility: Creating Inclusive Experiences for Global BrandsRegister Now
On Global Accessibility Awareness Day (GAAD), we don’t just reflect; we listen. This year, Isabel Holdsworth, a blind assistive technology engineer at TPGi, shared her experience traveling to Antarctica. It’s…
このページを最初にブックマークしてみませんか？
『TPGi - Your Digital Accessibility Solutions Partner!』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
