Guessing maybe the best approach here would be to just port this stuff to GtkIconView or are there any features in GnomeIconList that are a must have?

Adding the Sun a11y team on Cc:

In function gnome_icon_list_get_icon_text_item, there are some codes like this g_return_val_if_fail ((dx >= 0 && idx < gil->_priv->icons), NULL);
gil->_priv->icons might be zero, so evolution will crash. In gnome 2.13, all the critical warning will cause crash.
    I suggest that we can just assure the validity, and it is not necessary to report a critical warning. Possible code are like this:
if (dx >= 0 && idx < gil->_priv->icons)
    return NULL;
    You can transfer this bug to gnome ui group.

Yes, I think this is a libgnomeui bug.
Please change the bug's product.

I tried the suggestion from #3 here and I still see an invalid read of size 4 in valgrind and a crash when I do that. So it seems that even though we do that the call to         icon = g_array_index (gil->_priv->icon_list, Icon*, idx);

leaves icon->text bogus?

There's a fixme in impl_ref_child() that could be related:

        iti = gnome_icon_list_get_icon_text_item (gil, i);
        if (!iti)
                return NULL;

        /* FIXME: is this what we need to return?  How do we distinguish between
         * the icon text item and the pixbuf?
         */
        atk_object = atk_gobject_accessible_for_object (G_OBJECT (iti));
        g_object_ref (atk_object);
        return atk_object;

Kjartan, what is the trace of the new crash?

==13550== Invalid read of size 4
==13550==    at 0x455AD7E: gnome_icon_list_get_icon_text_item (gnome-icon-list.c:3174)
==13550==    by 0x455D70F: impl_ref_child (gnome-icon-list.c:3454)
==13550==    by 0x4D0573F: atk_object_ref_accessible_child (atkobject.c:657)
==13550==    by 0x41243E3: spi_atk_bridge_signal_listener (bridge.c:1030)
==13550==    by 0x4E3C66C: signal_emit_unlocked_R (gsignal.c:2404)
==13550==    by 0x4E3DD82: g_signal_emit_valist (gsignal.c:2197)
==13550==    by 0x4E3FC5D: g_signal_emit_by_name (gsignal.c:2265)
==13550==    by 0x455EE4D: gnome_icon_list_clear (gnome-icon-list.c:1419)
==13550==    by 0x402FBE6: update (e-attachment-bar.c:249)
==13550==    by 0x4030358: add_common (e-attachment-bar.c:157)
==13550==    by 0x64EEB8A: efhd_attachment_button (em-format-html-display.c:1588)
==13550==    by 0x64F037F: efh_object_requested (em-format-html.c:590)
==13550==    by 0x44BE64F: html_g_cclosure_marshal_BOOLEAN__OBJECT (htmlmarshal.c:83)
==13550==    by 0x4E2AEFC: g_closure_invoke (gclosure.c:490)
==13550==    by 0x4E3C90A: signal_emit_unlocked_R (gsignal.c:2438)
==13550==    by 0x4E3DC35: g_signal_emit_valist (gsignal.c:2207)
==13550==    by 0x4E3E028: g_signal_emit (gsignal.c:2241)
==13550==    by 0x447E04B: html_engine_object_requested_cb (gtkhtml.c:521)
==13550==    by 0x44BE64F: html_g_cclosure_marshal_BOOLEAN__OBJECT (htmlmarshal.c:83)
==13550==    by 0x4E2AEFC: g_closure_invoke (gclosure.c:490)
==13550==    by 0x4E3C90A: signal_emit_unlocked_R (gsignal.c:2438)
==13550==    by 0x4E3DC35: g_signal_emit_valist (gsignal.c:2207)
==13550==    by 0x4E3E028: g_signal_emit (gsignal.c:2241)
==13550==    by 0x44B2A18: element_parse_object (htmlengine.c:1529)
==13550==    by 0x44A996B: parse_one_token (htmlengine.c:3743)
==13550==    by 0x44B56C7: html_engine_timer_event (htmlengine.c:1348)
==13550==    by 0x44B5749: html_engine_flush (htmlengine.c:6479)
==13550==    by 0x447A4CF: gtk_html_flush (gtkhtml.c:5707)
==13550==    by 0x64F706B: emhs_sync_flush (em-html-stream.c:127)
==13550==    by 0x65064DC: emcs_gui_received (em-sync-stream.c:161)
==13550==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Created attachment 59983 [details] [review]
Patch

Patch for test

sorry, in comment 3 from Boby, one sentence is wrong.
if (dx >= 0 && idx < gil->_priv->icons)
    return NULL;

should be

if (dx < 0 || idx >= gil->_priv->icons)
    return NULL;


Please have a try with my attached patch in comment 8.

Looking good. I'll commit it after some more testing.

Commited.